On job titles and design patterns
I just changed my job title to say “Code Chef“. I like it, and it represents my current understanding of programming pretty well. I cook code. That’s my job.
Some N years ago I would have liked a title with “Architect” or “Analyst” or something like that. I would have called myself “developer” instead of “programmer” because hey, a developer thinks up things, whereas a programmer is a mere “code monkey”. More on code monkeys below.
But wait! Back then I also believed that knowing and using Design Patterns is essential for a programmer! In one place when I was interviewing new hires, design pattern knowledge was something I would look for… how stupid! Nowadays my view of patterns is more along the lines of “yeah, whatever”. I don’t exactly think of them as things from hell, but they could have caused more harm than good already.
Back to job titles. Code monkey is actually the key employee. A software product is largely defined by the code, heck, it is code. Sure, it also has the user interface, the fancy icons, the documentation, the website, the support, the roadmap and whatnot, but the code is the product, whereas everything else is more or less addons (possibly excluding UI… UI also defines the product).
Code design? Design patterns? Who cares about that.
It’s the final result that matters. Futurist programming for the win.
On the other hand, Memento Observer is probably very cool.
Which is why I like the job title upgrade from System Analyst to Programmer when I have switched jobs. I mean, the company I am working for is called “*Programmers* of Vilnius” :) I don’t think anyone would hire us to do programming if we were called “Architects of Vilnius”.
Anyway, do what you likes! I wish you a very happy future!
enjoy the life!
Thanks for the FTW – I’m enjoying your blog!
If you have an obsession with classifying the world, it becomes a much simpler place to live in, but you are also quite frequently wrong.
Although, since programming is a human framework, not a natural one, certain low level mechanics can easily be classified – although as with any system, at the higher levels of abstraction you gain more utility (development, or recognition speed) with patterns at the price of the optimal solution.