The Patents Cometh
I have an idea for a structured, dense-like object, solid in form, that has extensions coming from it. These extensions will be in random formation and will sprout their own extensions depending upon the execution of the algorithm. From those extensions fauna shall grow on a pre-determined cycle that interfaces with the weather patterns of the region where said structure is installed. Each structure shall be unique in nature, no two being the same. It will be glorious... I will call it a trei.
Now let's patent that badboy and go sue some forests for these knock-offs they are calling "trees".
There is an explosion taking place in the software industry (and/or implosion depending on how you want to look at it), where companies are bought solely for the stock in their patent portfolio (not for actually what the company can do) and seamingly disconnected companies are suing one another for infringements on patents.
I was doing my regular blog roll this yesterday morning and came across this article. I was stuck on this line for about 20 minutes - "Patents are the defense mechanism for capitalism.". Really? In a world where we are trying to marshal the growth of openness and networking through social media and other avenues we still keep a desk drawer full of papers to go - "aaah aah aaaaah, you can't do that". I thought the idea behind all innovation was to leap frog people's ideas and continually improve decrepid systems making them more functional and useable then they previously were? How do you do this? You build a better mouse trap. You are still going to have tenets of the original design - i.e., its goal is to catch a mouse and there might be some spring-like action to it, but apart from that they would differ. And then shouldn't the original company be all like - "Well we built the first mouse trap, so let's go build a better mouse trap then so and so?" Isn't this where innovation begins - find a problem, fix it, release it, keep making it better.
I'm not a Patent Lawyer, I don't know all the ins and outs of the system (and I have no desire to be). I recently had the opportunity to speak with a trademark/patent lawyer this past week who basically said - "I hate filing patents". He made a real interesting comment that the work involved in procuring a patent is not in the process itself, but in the marketing of the patent and the enforcement. Where companies originally started as doing this to defend themselves, they are now using them as revenue generating models to account for a growing percentage of their income. Translation - some companies survival is becoming based upon the execution by of your idea by someone else. This isn't a defense against capitalism, this is laziness in its simplest form. And if you are spending millions to enforce patents, what else could you have done with that money? Build a better product, streamline a new process, throw a party for your company?
I've been involved in a few internal mail threads related to patents, I immediately deleted them because the proposed content was so generic that if ever enforced would limit developers in doing their actual job. Can you imagine as a Developer, having an idea, you think its great, you want to run with it, but before you drop a lick of code your manager asks you to go check the patent database to see if one already exists. If it does, sorry not going to do it, if it doesn't, patent it and sit back and wait for the trolling to begin... en masse. You might think its at the far right at the spectrum, but this is where we are headed.
I really hope this trend ends at some point, but I don't see it happening soon. My favourite part of coding has always been sitting in a room with a few people, thinking up ideas, trying them out all while working toward a goal to release a great product. If that mindset is changing to coming up with an idea, filing a patent, waiting for the patent, trying out the idea, giving up (because we invested more in the patent process then the actual job and now need to drop people) and then waiting for someone else to do it to collect revenue... that just seems wrong, you don't deserve it, you didn't earn it.
Oddly enough after writing this yesterday I cam across this article on CNET, timing is everything.
What's the Big Diff between Juniors and Seniors Titles?
If you were to take a quick scan of the current job market you’d see many development positions prepended with the generic – Junior, Intermediate, Senior headers in front of them. Nowadays we are getting really fancy because we need to attract new MORE qualified people by using such terms as Guru, Expert, Ninja, Rockstar, etc, etc, etc.
Can you really look at these designators and apply them so broadly to a field that is still so young and so widely influenced by external factors?
Generalist vs Specialist
Developer A is a Java back-end developer; he understands database protocols and is well-skilled in database design (particularly Oracle). He has been working in this field for approximately 12 years. His work is solid; he understands what needs to be done and the gotchas to look out for; however his experience and knowledge is solely focussed on data and no other area.
Developer B is a .NET developer; she doesn’t really specialize in any certain area, has some well-applied experience in WPF, WCF and WF. She is not nearly as experienced as Developer A but she knows how the different parts of how a system works together and what caveats need to be in place for the different technologies to align.
So – who is the Junior and who is the Senior? If you go by total years of experience then you are essentially placing your bets based on performance in a single area vs a span of information across disciplines? (forget the fact one is Java and one is .NET, that serves no value in this discussion) Although I would not think Developer B to be at the level of experience of Developer A, they do have something going for them in that they understand multiple facets and protocols of development and programming which would lend them to working in multiple areas and understand the need to twist indexes and database return results to fit the needs to small networks and such.
Veteran vs Noob
So let’s say we still have Developer A and B in our scenario, Developer B has been with Company X for her entire career to date (5 years) and has worked with the company’s products since Day 1. Developer B has come on board to solve the company’s data issues; he’s got a lot of experience but knows little about the Products. In meetings, Developer A clearly has more influence with the rest of the project team because of what she has accomplished to date and her sound knowledge of the company’s products. While on the other side Developer B is struggling to get buy in for his ideas? However, Developer B’s suggestions are incorrect in some facets, primarily because she doesn’t have the required experience in that field to make the kind of decision that developer B can but she is regarded as being a more Senior developer because of her internal experience and product knowledge.
We have now crossed over to including Product knowledge and past successes into the definition of a Developer. Developer B has delivered some pretty solid product and knows the suite inside and out (which is good) and has built up credibility with her team to trust her decisions (again good). But now she has been put into the position to make technical decisions related to a technology area she does not understand and has not worked with. In essence she was promoted into a position where she was not qualified to enter but based on what she did for the company, it seemed like the right thing to do.
Whether we like it or not, Product/Company knowledge indirectly becomes key decision criteria in determining what level a developer is at. Sure we can peg them at Junior, Intermediate or Senior on Day 1. But after that, their stock starts to go up with every release that goes out the door (and these factors are quite complimentary). Have a good understanding of the product and you’ll know how to better code for a problem. Need to implement a new feature under the gun? Well you know the codebase so get to it and Ship It!
So in the end does it matter if we call people Junior, Intermediate or Senior? When you enter a new organization, in some ways you are really a junior once again, you might re-accelerate to Senior quickly but you still have to contend with the internal product experience already acquired by internal resources that have made them more than what they were when they signed on. And really, who is going to put a new Senior Developer on a mission critical outage on Day 1? No one (at least no one in their right mind who wants to see the bug actually get resolved), so in the end why not just call us what we are – Software Developers – those of different skills, capabilities and knowledge.
Now if you’ll excuse me I have to go get ready for a dentist appointment with my Senior Dental Hygienist and Junior Dentist (see doesn’t that sound dumb)?
Now that's a new blog!
Okay so I am a bit behind in migrating the old girl from last year's v1.5 to v2.0 of BlogEngine (version 2.5 is in RC mode right now), but at long last it is finished. The process itself wasn't too bad, I started Friday night, download the updated SDK and was able to migrate a lot of my blogs relatively quickly. Where I ended up spending a lot of time was in the look and feel and theming of the site.
Over the next couple of months I want to start adding some Widgets (see right-hand side) for Hubspot and Twitter feeds, right now the Hubspot blog grader is completely hacked in and I'd like to not have to do as many web customizations moving forward.
The guys at BlogEngine have done a really great job, the Admin UI is much easier to work with now and I like the overall look and feel of the new pages.
One thing for sure, I have been out of ASP.NET, CSS and HTML5 for waaaaay too long.