Discipline Makes Strong Developers

Regarding the perceived opposites of being lazy and being disciplined, this is because there are good and bad sides of being lazy, as well as good and bad sides of being disciplined.

Being lazy can mean that you don’t bother with following code conventions, testing and sanity checking, documenting or figuring out reasonable names and designs. Being lazy can also mean that you’re not making your code or designs more complex than they need to be, not implementing functionality that won’t be used, or reinventing the wheel.

Being disciplined can mean that you can stay focused while you’re writing thousands of lines of unnecessary convoluted code that will be impossible to maintain and wasn’t needed in the first place. But of course it can also mean that you’re making sure you’re doing a good job.

The right kind of discipline and laziness are essential traits for good developers, I think. Me, I am both lazy and disciplined, although not always in good ways.

You’re also making the assumption that developers are given the minimum amount of time and resources to allow discipline to make a difference. The company I currently work for lives by this motto, “Broken functionality today trumps properly designed code tomorrow.” The ONLY aspect of software development that matters to them is ship date. Doesn’t matter if the product wasn’t designed, didn’t have enough time for development, no documentation, and that QA time was skimped or eliminated, as long as the artificial ship date is met, all is good.

If your fundamental foundation of software development is flawed, discipline can take you only so far and beyond that you can be the Anal Retentive Chef and it won’t make a bit of difference.

In response to Teresa, I’m about to graduate with a Infomation Systems degree and my University only teaches object-oriented languages. I believe flow charts are more important in procedural languages.

However, all of our professors did stress the value of clean, maintainable code.

Remember what happened to Gunnery Sergeant Hartman? Good luck, enforcers.

1 Like

Is that Scott Hanselman’s desktop? :stuck_out_tongue:

This topic hit the nail on the head, IMHO. Thanks Jeff! Have the discipline to stop and think, have the discipline to consider the goal you are trying to achieve, have the discipline to make sure the code you are about to write was designed, have the discipline to make sure the design meets the goal you are trying to achieve. Oh yeah, have the discipline to make sure that goal is something in the business requirements or needed to meet the business requirements.

You are paid to build software that meets the business’ needs. It is not play time.

In response to Patrick:

Writing programs with good flow also comes up in OOP. When you are on one of those projects that is 500,000 lines of code you will find that at some point you have to solve a problem that requires a procedure. Right there in the middle of your object is a method that has lots of if and switch statements.

I like this quote, which apparently was said by Confucius:

“By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.”

Perhaps substitution of “software development discipline” for “wisdom” works as well.

Being held accountable for low-quality work and having to spend late nights and weekends to fix it is definitely “bitter” and will either make one straighten up and fly right or fly the coop in my experience. Of course, having to do that fixing someone else’s work will also motivate you to elevate the level of discipline expected on a team.

Having a good mentor to learn from and a good set of software practices and accountability measures in place can definitely make the development more disciplined. Being naturally well disciplined is somewhat of a rare situation, I think. I think we all benefit from having an environment where excellence is expected and measures are in place to get you there.

The lure of good paying salaries and benefits in an air conditioned work environment, driving a desk is unfortunately a motivator for many who couldn’t give a flip about developing quality software. I’ve worked with too many of these types over the years and it can drag you down if you actually care about producing quality. But that is a different matter.

Published coding standards, and then code reviews.

Jeff, I’ve been reading you for months, but this is the first time I’ve forwarded your post to every developer at my company.

Outstanding post, soldier.

I understand the need for coding standards. I follow some myself that I’ve been “brain washed” into following from companies I’ve worked with before. But while you’re trying to “brain wash” your group of programmers to follow a particular coding standard, don’t end up like Gunnery Sergeant Hartman. :slight_smile:

Teresa: I’m working on my Computer Science undergraduate degree right now, and fortunately for me, my university does have a class which is almost exactly as you describe; it’s called Software Modeling and Design. It is required for every Computer Science and Software Engineering major, and covers the use of UML to design software systems. I’m actually starting this class tomorrow :wink:

Take heart, not every university is afraid of being “too boring.” There are still those who care about real education!

Keng: I think the good serjeant was using it in the sense of being able to cut the mustard - as in, if you can handle it, you can hack it, and thus you are a hacker. If you follow me.

Great Post – Liked it almost as much as the Glengarry/Glen Ross post.

You left out one big word: Authority. The drill sergeant has authority over his “pukes”. But who in management has delegated the authority to enforce discipline on developers? In my experience, one of the biggest and realest problems that companies face is that they don’t have development leads who are given both the time and authority to enforce discipline.

I fluctuate back and forth on this issue. Sometimes I think we need less discipline, not more.

One thing engineers need to accept is that there are very few instances in which there is one right way to do things. And under the right circumstances, the wrong way can be the right way or at best, inconsequential. Exhibit: A - Linus developing Linux with tarballs and patch files for 10 years.

Another thing engineers need to learn - your desires for engineering “cleanliness” is subservient to the needs of the business. Too many software guys think we code inside a white castle where money magically appears in our bank accounts. You could probably make an interesting blog entry on this topic (assuming you understand it yourself of course :slight_smile: ).

I find myself being that person now, even though I am not technically a supervisor, I have to frequently remind the other developer that I use conventions when writing my code, and he should do the same.

I have to wonder how disciplined Microsoft developers are. Clearly there are no set conventions among their millions of lines of code. Just imagine how much faster the computer world would move if there were. There would be less bugs and vulnerabilities, fixing the few that exist would be easier, and life as a third-party developer like me would be so much easier. Having delved deeply into the office interop objects in VB.NET, I can tell that office is a core set of objects built long ago with added features just duct-taped on with little regards to the way it was originally designed.

In general, discipline can come from yourself, as well as others. Ideally from both early in one’s learning curve.

I am reminded of my humble beginnings in programming, where I was the lone programmer. I don’t recall if it was you, but someone I read before mentioned the dangers of programming in isolation, the breeding ground for bad habits.

Luckily, I did recognize this somewhat and consciously attempted to read about and develop good habits. When I switched jobs and joined a real team, much of that stood me in good stead, but I also learned just how much I hadn’t managed to learn.

Incidentally, in those years as lone prorgrammer, I had three teammates but they were 200 miles away in a different office (and not exactly models of programming discipline themselves). Sadly, my current job has decayed into much the same environment, and I notice old habits trying to creep in again.

One of the best ways to become excellent at something, is to surround yourself with others who are excellent at that thing.

I actually often quote Full Metal Jacket to newish people on the team. Now I know I am not alone.

I think code reviews also help flush the Sh*t out…

I agree with you Dean. Out of all the factors involved in a successful project I think code organization and variable naming standards have a small effect if any. Competency is the REAL issue. One competent dev can easily understand another competent dev’s code. period. Organinzation and discipline is helpful for the hacks to understand their own and eachother’s work.