(Posted on the article too, but might be more use here) Nice set of articles, but a teensy bit one-sided in places.
What about the programmer who comes across as being a prima-donna about introducing some flavour-of-the-month practise, but who isn’t able to justify it in terms of measurable impact on the bottom line to (say) a small business owner. Often they’ll be right, but frequently they’ll be wrong too. I’ve often been guilty of this as a programmer–I want to change some code to make the design more elegant, add more tests etc, but if pressed it’s hard for me to say whether the improvement adds any value for the business. Sometimes it will, sometimes it won’t. Sometimes despite its value the opportunity cost may be too high. Either way as a ‘good programmer’ I will feel strongly about the matter, and it’s my boss’s job to try and temper that programmer “I only want to work with good code!” gut feel with a bit of business-oriented practicality.
So yes, the extent to which you indulge the 'great programmer' is always going to be a tricky call, especially for the non-technical, or even the technical-but-non-specialist. On the one hand you don’t want to piss off the talent–and let’s face it, some (not all!) of this stuff really is just that, in the same way a hollywood producer lays on whatever perks the best actors demand. On the other hand you need to have confidence that there’s real business value in activities that are being proposed. Or if not immediately demonstrable value, a way to measure reasonably objectively over time what impact they’re having. For example, Google (from what I hear) have an amazing system to measure (in some reasonably useful sense) the value of every test that gets written.
On top of that, sad truth is that a lot of companies don’t actually need great programmers. Sure, all else held equal they’d like them, but they’re expensive, they often want to spend your money bringing you into line with the latest and greatest–and sometimes it really is sufficient just to keep some old ball of code ticking along. I wouldn’t really want to work for one of these places, and doubtless neither would you, but it’s an acceptable deal for some programmers and some companies, and there’s a more nuanced perspective available than just to patronise them.
The other thing with great programmers is that if you don’t give us a sufficiently interesting problem to work on, we’ll often go and invent our own (whether consciously or not).
That might be a plus for someone like Google, or sometimes for some kinds of start-ups, but not so much for some more pedestrian smaller businesses.
Or perhaps behaving like this makes one not a great programmer, depending how you define it. It's not a one-dimensional quality I suppose.
> The other thing with great programmers is that if you don’t give us a sufficiently interesting problem to work on, we’ll often go and invent our own (whether consciously or not).
> That might be a plus for someone like Google, or sometimes for some kinds of start-ups, but not so much for some more pedestrian smaller businesses.
If you actually like programming (as oppose to pursuing it for the money), you should only seek to work at places where you, as a technologist within your particular field will make a difference.
Problem is that it's tricky to tell such places apart from the rest. Everyone calls themselves a "technology company". Mission of the company isn't a good heuristic: there are e-commerce retailers that are run like "IT shops" and there is Amazon (a true technology company). Nonetheless, from this message I can tell that something is different here and better here:
In most other cases it isn't so clear; you have to read between the lines. Job descriptions only asking for years of experience with specific technologies, non-technical interview questions or interview questions that only involve language syntax and APIs but don't touch on algorithms and data-structures, inflexible working hours, mandated technology stacks (with no exceptions for new projects or experimental code) are a way for an employer to signal "hackers not wanted". Fortunately these are very easy to spot and avoid, but I've been surprised when people (who have other options) choose to work at companies that require them in their seat at 8:30 and clearly under-use their talent.
On the other hand, I am afraid excessive commitment to methodology (e.g., daily stand-ups, inability to write any code without meetings + permission of the "scrum master" + index cards, pair programming, mandated test coverage percentages and "always write tests first") is another such sign, but unfortunately I am in minority.
Send us your resume in raw text format. Word resumes will be discarded.
Experience with an OO language (Java, C++, etc) is required.
In your cover letter, tell us about a non-mainstream technology you love.
What about the programmer who comes across as being a prima-donna about introducing some flavour-of-the-month practise, but who isn’t able to justify it in terms of measurable impact on the bottom line to (say) a small business owner. Often they’ll be right, but frequently they’ll be wrong too. I’ve often been guilty of this as a programmer–I want to change some code to make the design more elegant, add more tests etc, but if pressed it’s hard for me to say whether the improvement adds any value for the business. Sometimes it will, sometimes it won’t. Sometimes despite its value the opportunity cost may be too high. Either way as a ‘good programmer’ I will feel strongly about the matter, and it’s my boss’s job to try and temper that programmer “I only want to work with good code!” gut feel with a bit of business-oriented practicality.
So yes, the extent to which you indulge the 'great programmer' is always going to be a tricky call, especially for the non-technical, or even the technical-but-non-specialist. On the one hand you don’t want to piss off the talent–and let’s face it, some (not all!) of this stuff really is just that, in the same way a hollywood producer lays on whatever perks the best actors demand. On the other hand you need to have confidence that there’s real business value in activities that are being proposed. Or if not immediately demonstrable value, a way to measure reasonably objectively over time what impact they’re having. For example, Google (from what I hear) have an amazing system to measure (in some reasonably useful sense) the value of every test that gets written.
On top of that, sad truth is that a lot of companies don’t actually need great programmers. Sure, all else held equal they’d like them, but they’re expensive, they often want to spend your money bringing you into line with the latest and greatest–and sometimes it really is sufficient just to keep some old ball of code ticking along. I wouldn’t really want to work for one of these places, and doubtless neither would you, but it’s an acceptable deal for some programmers and some companies, and there’s a more nuanced perspective available than just to patronise them.
The other thing with great programmers is that if you don’t give us a sufficiently interesting problem to work on, we’ll often go and invent our own (whether consciously or not).
That might be a plus for someone like Google, or sometimes for some kinds of start-ups, but not so much for some more pedestrian smaller businesses.
Or perhaps behaving like this makes one not a great programmer, depending how you define it. It's not a one-dimensional quality I suppose.