Scott Koon recently wrote about the importance of discipline as a developer trait:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/08/discipline-makes-strong-developers.html
Scott Koon recently wrote about the importance of discipline as a developer trait:
Now I have to re-watch this movie again. Great movie.
If you want discipline, I highly recommend taking the Personal Software Process: A Discipline for Software Engineering course, or at least reading the book and following the exercises.
I know many people think it flies in the face of the popular Agile methods, but I’ve used it on a project that had as many as 18 people at once, with changing requirements, changing staff, deadlines, etc. It is the only project I’ve worked on where we met every deadline and had an extremely small number of defects.
PSP feels heavy, especially when you’re first learning it. But once you make it a habit (aka become disciplined), the perceived “overhead” is more than compensated for by time that would otherwise be spent testing/debugging.
"There should be a Gunnery Sergeant Hartman on your development team who will… gently… remind the team that it might be a good idea to fix problems like this before they become institutionalized in all your future code. "
In a previous job I was definatly that person, trying to standardize and as you say ‘gently’ remind people that these things need to be sorted. The problem is that unless you can get people to switch over to ensuring the standards are followed and checked as part of the routine you soon begin to feel like your constantly nagging, and thats not nice
When developers on our team take the time to do these kinds of things properly we call it “Leading by example” And leadership is one of our performance review topics.
“Now, lean over and choke yourself!”
Biggest trick I’ve found with this sort of leadership in setting up discipline is the requirement of setting an example. “You’re going to come help me do this” works a lot better than “Go do this.”
I’ve just been thinking that I need to force myself into a more disciplined coding approach, no matter how quickly the deadline is looming.
Oh, and does anyone else find it amusing that nigger is censored but there’s no problem saying wop, kike, or greaser?
I wonder what is in that “women” media file on that desktop image…
@dang - I took the PSP course and also certified to train PSP. I agree what it can work and that it feels heavy. I think the principles that Watts and company encourage are good - it is good to be able to estimate well, it is good to have checklists for reviews, it is good to review design and code, and it is good to do some sort of measurement of your progress. My experience was that without institutional buy-in, PSP (or maybe any methodology for that matter) has little chance of succeeding. The “Executive Summary” book that Watts wrote would likely provide management with information that might get them on board, but getting them to actually read it… that’s the first trick.
I still have an early draft of Humphey’s “Leading a Development Team”, and believe it has a lot of valuable insight. Glad to hear it worked for you.
Can I be the someone who points out that you typo’d on ‘someone’ where you say, ‘or perhaps somone with the right’?
My issue is when I bring these issues up with many programmers, they tell me ‘everyone has their own style’. They somehow chalk up deficiencies as their own special brand.
My other issue are programmers who never seem to stop and think, ‘there has to be a better way to do this’. They just write what comes to their head. And then I’m considered an elitist when I replace their 27 line subroutines with 1 line.
need more discipline? R. Lee Ermey has a podcast, too (via Scott K):
Also, you can buy the 12" R. Lee Ermey motivational figure with “x-tra salty” recorded phrases.
Discipline? I always thought laziness is a virtue for programmers. Maybe the two aren’t mutually exclusive, but we like to think they are. Hmmmm… Can one be lazy and disciplined?
david h: I’d suggest being disciplined would actually help you be lazy.
Disciplined code results in easier to manage, less likely to break, less work to understand later code.
So writing disciplined code means less work later managing it. A lazy person’s dream!
Many years ago, I was running a code review for some software on a major DoD project we were testing. Now, remember, this was MANY years ago: our two languages were Fortran and Assembly. Just from the constructs available in the higher-order language (that’d be Fortran for those of you without a history course under your belt ), you’d think the Fortran modules would be better-coded than the Assembly. Well, you’d be wrong. The Assembly code was FAR more structured and maintainable than the Fortran code. Someone at NASA (the originators of that Assembly code) definitely had the discipline to force those programmers to produce highly maintainable (heck, it was practically elegant) code. The contractor for the Fortran code, using the very same standards, didn’t force the issue and ended up with merely adequate code.
Discipline is an absolute requirement for good code. If management won’t do what they’re paid for (manage and control the software development process), then programmers will have to do it themselves.
@dnm (and Jeff)
dnm, I feel your pain… I think those are extremely cogent points.
What the programmers who don’t think ‘there has to be a better way’ aren’t doing and should be doing is this – (and this is a good idea for a post, Jeff) –
Great programmers talk about programming.
It’s that simple. That’s what we’re doing here and I’d bet that’s what you do with (at least one of) your teammates. You get better at what you do by talking about how to do it better.
That’s why your routines are better, dnm!
I think that for establishing discipline it should be mandatory for all developers to establish and maintain some assembly code (something in the range of 1000 lines), anyone who doesn’t have discipline will be pulling the flippin’ hair out after a week. This will also help with documentation (we call them ‘comments’) when someone has nested functions that are pass by value-reference. I learned more about discipline writing a few hundred lines of SPARC ASM this semester than all of my C++ for the last 5 years. If my macros for registers didn’t make sense, I’d know after about 100 lines.
“And my orders are to weed out all non-hackers…” WOW the corps was building hackers way back then!..sweet.
This will certainly date me (okay I admit it - I’m old) but back in “the day” colleges used to offer computer logic classes. The class was not writing code, it was writing flow charts - the logical set up of a program. Naturally, as it was college, these were single programs doing one task, but learning to structure a program first makes everything else so much easier.
I haven’t seen a class like that listed anywhere for years. The shame of it is, once I took that class, every type of code writing became a matter of simply learning the syntax - the rest of it falls right into place. If you extrapolate, the logic can easily be extended to work projects that include multiple files in a tree structure.
I guess it was deemed “too boring” by the CS departments because it never involved any of the latest and greatest cool code and seems to have disappeared from the scene.
I am sure this is one of the biggest reasons that so many projects are in such disarray.
There’s also the issue that there’s a large number of people who genuinely have no place in this field at all. They just think there’s money to be had. Sadly, there is money to be had, because many hiring managers aren’t able to weed out the crappy ones.
You really made me flash back to when I was a newly minted programming graduate. I knew all about recursion, data structures, 3D vector math, database theories of normalization and unix scripting commands. What I didn’t know about was project planning, code commenting, variable naming schemes, choosing the right “X” for the “Y” or any of the other functions of the business of being a programmer. I had graduated from a major state university known for technical skills with all of the training to be a script kiddie. That first year getting indoctrinated into the mysteries of producing code to spec on time and in budget was a real eye opener.
Perhaps what we need the last semester (or first semester) of CompSci to be is boot camp. You will learn to write good code, cleanly and clearly with useful comments and well defined outputs and error handling. Or you will drop and give me 20!
I always thought that a good programming excersize would be to have each person in a class write a function to do something simple, like shuffle an array. Then everyone passes their code one seat to the right and then you have to take someone elses function and use it to sort your deck of cards in your data structure. Then you pass it to the right again and use that code to deal out 4 hands of cards. Then pass to the right again and use that code to determine the winning poker hand. Keep passing code until you have a full poker application. Let people see how much fun it is to inherit bad code from someone else and they won’t be so fast to write it in the future.
In response to Teresa here, I as a recent graduate of an Information Systems program did do flow charts in our introduction to programming course. I think it is something that is still around, but it’s been condensed into the beginning programming courses as opposed to being it’s own dedicated course.
And yes, I wish I were more disciplined when I code, hopefully with expierience I will learn