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
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/08/discipline-makes-strong-developers.html
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.
http://www.amazon.com/Discipline-Software-Engineering-Watts-Humphrey/dp/0201546108
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):
http://www.rleeermey.com/podcasts.php
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!
g
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 