After a five-month ski vacation I'm back in civilization job-hunting. The interview process is interesting from the interviewee side, to see what many companies think that they want. To me, a good programmer isn't someone that's spent seven years with Technology X; in that much time one learns a lot of tricks, but good programmers don't just know tricks - they're supposed to be writing code.
#1 Ship
Good programmers finish what they're working on. I think being left in a cubicle by yourself makes it easy to succumb to creeping featuritis. To get caught up in 'perfecting' a system which might have a minor role in the finished product. Good programmers ship. They get things in shape to release, and they release. The more things you release, the more you learn about what customers want. And you also learn how to release better software faster.
To me the lesson of Outliers is that everyone learns by doing. The more you do something, the better you get at it. The people that are really good at stuff - from major-league sports players, to Bill Gates, to writers and artists - are good because they have had a lot of practice.
Spinning your wheels polishing bad code is practice polishing, not practice shipping. If you want to hire a good coder, you want someone that's had practice turning a working prototype into a professional, shippable product.
#2 Working
It a similar vein, good programmers write working code. I've worked with too many coders that write buggy code that barely works - or doesn't work at all. You'd think they wouldn't still have jobs programming, but the interview process is pretty damn flawed. It's like a first date. The interview I had today was mostly feel-good; a guy on the team liked talking about Agile and I could talk the talk. Walking wasn't really part of the discussion.
I'm surprised when I see someone check stuff in that doesn't actually work. It suggests that the programmer has bad habits and doesn't test what they write. To them, programming is something you do in the editor. As soon as their code compiles, they check it in and move on. Yes, I've actually worked with coders like that. They think they're gods; they think they don't make mistakes.
The good programmers on your team, the ones you want to keep and promote, are those that actually get stuff working. When a web page is supposed to do something, when a class is supposed to commit a transaction or pull data, it should do so. Some guys get 90% of the way there, and other coders step in and turn a code checkin into a working feature.
Mr. 90% won't be able to ship software. He might write a lot of code, but the stuff he checks in doesn't actually work. Ask your coders; they'll be able to tell you who on the team is Mr 90%. Fire Mr 90%.
#3 Robust
There's a lot of work that goes into the "foundation" of a feature. Some of it is gruntwork; creating the class, getting headers & dependencies set up; building the UI using a design tool. This is mostly monkey-work, and that's why bad programmers can get to 90%. Getting stuff working is the last 10% of the code that's written, but it's an essentially important 10%.
But once a feature works doesn't mean the work is done. Debugging typically doesn't add lines of code. Refactoring to get stuff working is likely to reduce lines of code. Good coders don't just run their code to see if it works; they test it, too. And they know how to write software that passes tests, and how to write tests that go after edge cases and corner cases.
Going after those edge cases is a mindset. Some programmers have, in the back of their mind, a demon that thinks of malicious calling code. What's the worst that can happen? What if they give me bad data? What sort of bad data is there? Are there possible race conditions that could screw up this process? Good coders have that demon.
"Agile" has turned into a buzzword that many software managers think they need to have. They think writing tests will remove all bugs. But if your tests don't test the right stuff, then your product will still have bugs - it will just take live testing by a QA group to find them. There's good practices in agile testing, but TDD won't get rid of bad programmers or make them irrelevant. The guys you want on your team write robust code the first time. That doesn't mean no bugs but it does mean they, as a habit, look for edge cases.
#4 Features
I think somehow it has become verboten to discuss intelligence. Yet software is one of the few areas where intelligence has a very strong effect on productivity. Smart programmers get more done. They are good at solving problems, and they can keep track of several things at a time. If they need to keep that "what if" demon running in the back of their mind, the smarter guy will have an easier time at it.
Good programmers get features done faster. Per week, they get more features done.
It's grossly difficult to schedule software development. Agile development, in part, is a response to that. Instead of making up a list of features and then committing to a length of time to get that done, Agile commits to shipping something at a point in time. Some features are easier than others. It's hard to actually measure programmer productivity - but still true that good programmers are more productive.
Shipping Feature-Rich, Robust Software
Software development is about shipping. Guys in academia and research departments can fart around for decades and you can call it good work, but out here in the real world we need to ship software. The more features you have, the better your market position. The more robust your software, the happier your customers will be.
Good programmers make that happen. They write the code, it works when they check it in, and they know how to go after bugs. And they do it all quickly.
Hire those guys; they'll make you rich. :)
No comments:
Post a Comment