You’re a Bad Programmer, Really?

“I’d argue any work package (WP) larger than 1 to 3 days can not be easily estimated.”

Well said, and your coverage of the management issues is to the point. Nice post.

Couldn’t agree more with this post. Those 9-5 “day coders” are the ones who do not see programming as a craft that has to be mastered, but as a job that simply pays bills. The claims by the other post that you quote are simply outlandish.

I think you got a bit too serious about his post.

Yours sound a bit like a whining child trying to defend itself :-)

I saw his post as a ironic thread to face the fact that programmers should not be to confident of their daily work and therefore it is required to have tools work side by side with them.

So more a post to “wachrüttlen” than to show the pure funless facts.

“Good programmers use tools, [...] bad ones don’t – they do not see the need and benefits of tool usage. Good programmers demand the introduction of tools.”

+1 !

And then again there are companies who do not get that, and unwittingly restrict the introduction of tools, thus blocking even their good developers for some obscure reasons instead of bringing them to their highest productivity.

Great points Stephan. The referring post seems to have been written by someone with a very thin view of what programming is. Mike Cohn’s Agile Estimating and Planning, Software Craftmanship Manifesto, Extreme Programming Explained by Kent Beck, Lean Startup techniques and RethinkDB’s infamous “Will the real programmers please stand up?” (http://www.rethinkdb.com/blog/2010/06/will-the-real-programmers-please-stand-up/) are recommended reads for anyone who even dare to say or agree with such a bold statement.

Heh. That’s like saying all writers are bad because they need editors (human), proof-readers and spelling-checker.

[...] I’m picking on this guy, but he brings up two things that really irritates the living hell out of me about our industry. [...]

Oh Stephan, the “refering post” I mentioned was Jared Richardson’s. I am sorry it was unclear. I expected you to know/have read/twitted about the books/links. I just mentioned as added bonus arguments to the point you made.

just ignore the first 5 paragraphs of the mentioned article and also take a look at how it’s been tagged. these initial paragraphs are just to justify the screaming title.

i agree with both of you :) strive to be a better programmer and make sure to use the mentioned tools because we’re only human …

Really, you are pulling out Agile as an argument here? I think all the “good” programmers realized years ago that Agile was a scam.

That’s been a nice post. But I think you’ve missed the point. I understand that you want to “send a signal” saying we all can be better developers, but no one can become better if he is already thinking that he is really good at what he does. So, the point is (IMHO) that we all should assume (and embrace) that we make mistakes, forget things, and break designs, no matter who we are or what our experience is, and so, we have to be constantly looking for the best tools and the best practices to help us to do our work right, and trying to become a better developer.
Of course there are good and bad programmers. But the the difference is that good ones think they have to become better, and bad ones are not interested or think that the already are good.

I still believe you misunderstand the intension of the article, for me its basically what dagarfol said.

The article should open ones eyes (and this is done in a provocative way), dont be too sure about your skills and experiences, think outside the box. Dont try to be smart and reuse proven good stuff.

at least this is what i read from that article (together with a little smile on the face) :)

Well that article only points to newer programming languages. Old school mainframe developer like me doesn’t have the luxury of auto-completing IDE or even an IDE. He!

If you will be judging a developer it should not be as a group because there are other factors that needs to be considered. Most group projects are led by team leads or managers.

Unlike a developer who does end-to-end, he/she shoulders everything from the analysis of the business need/requirements, planning, coding, testing and implementation.

Actually there are a lot of things you could do to improve your skills. And from experience people who rely too much to code re-usage is what makes them dull. practice and be creative with your programs.

Well as a programmer I believe that the tools help you get everyday work completed faster. In my particular case this free’s me up to explore the new concepts and new idea’s, which is how we become better.

Dependence on tools for code completion and compilers for syntax checking isn’t a bad thing, it means you don’t get caught up in the particulars of a language and lets you focus on the “actual” problem you’re trying to solve. In my humble opinion a good programmer transcends language and deals in only the problem domain. This lets him choose his tools to complete his job in the best, and fastest way.

After all we’re all problem solvers at the end of the day, so if you’re a bad programmer, you’re probably just a poor problem solver.

I take issue with the very first blurb from the “bad programmers” article that is quoted.

The idea of using an IDE meaning that you are a bad programmer is the wrong measurement. IDEs deal with code specifically. Good programmers not only work with code, but they work with logic and data organization (and more). A great programmer might miss 6 semicolons on the way to an awesome finished program (well, not as often with the newer IDEs, but it was a pretty common error in the old Borland C++). A bad programmer can write a buggy program that inadvertently destroys your data and compile it successfully on the first try.

Honestly, I think that it’s not necessarily true that relying on technology instead of memorization means people are failures.

I use calendar software because it’s better at remembering and reminding me of activities; does that mean I’m dumb? No, it means I use my brain for CPU, not RAM — that is, I think, not memorize.

Andrew, Sheeri, totally agree, it’s not the tools that help you get to your solution but “how” you get to that solution that makes you good. Spend more time understanding the problem, and if tools help give you more time to do so than they can only be a good thing right.

I’m just quibbling here, but I’ve found estimation accuracy tends to peak around about 6 weeks. Tasks that are just a few days long are too subject to wide variability because they tend to be either much easier or much harder than estimated. The differences start washing out when the one day tasks that turned out to be an hour and the ones that turned out to be a week are all lumped together. Also, I find it helpful to look at the tasks as a bunch and say “I think it should take this much” and compare it to a bottoms-up estimate. If the two are widely different, then there’s a probably a problem with both estimates.

[...] You’re a Bad Programmer, Really? [...]

I think the argument you make about using tools — good programmers use tools, bad programmers just don’t see the point and don’t — also apply to things like Agile and scrum. Good programmers realize that when doing projects, the process matters.

Now, that applies both to the good programmers I know that like Agile stuff, and those that are very much against it. In any case, they’ll have thought about it, and have chosen to work in the way that fits them best.

The bad programmers? They just don’t care. Or they just care enough to want to put a buzz-work on their CV’s, say they’re doing Agile, and in reality just do things like they’ve always done.

I have been a professional software developer for 15 years, add some 6 years more of unpaid exploration before that.

Usage of tools or the decision to use tools have never made a bad programmer a good programmer. My theory is that some people are just born with the right traits for the job and then there are those who were told it was a good career.

I led teams ranging from 2 to 30 people, which involved supervising deliverables and thought processes ranging from “this is how it is done” to “why are you here?”. I have never seen a bad programmer raise to a passable and stable level, no matter how much effort and coaching was put into his/her development.

1, “I’d argue any work package (WP) larger than 1 to 3 days can not be easily estimated.”
If you can’t envisage a scale of work over 3 days, that is codemonkey, not programming. A major project can take months – even years, and stay within the original estimates.

I do not understand your second tenet.

“3. Features are added all the time leading to scope creep.” Agreed. This is dealt with by getting agreement from all parties before design and development starts. Any changes mean that the whole design/review/approve process starts again.