Dot Mac

Bravo David!

I have always maintained that top-down thinking is way better than bottom-up coding.

I disagree with the previous commenter who disputed that lessor folk will be obliged to maintain the code, although if you’re truly great, maintenance will not be an issue.

On a not totally disconnected point, I always feel that if a “User Guide” is required, I’ve failed.

I once asked a colleague (who could lecture on SDLC in a world-class capacity) what is project management other than identifying and making happen the activities required that arise from the need to recover from fcuk-ups – he said “nothing – that’s about it”.

“Requirements Document” – a mythical entity that, despite the title, will never fulfill the overall objective because no-one actually knows the full extent of what’s needed now, let alone that which will become apparent during the course of development. As for that which becomes apparent in the future – well … take a guess.

“Needs Analysis” – another mythical thing that will never see the light of day in the absence of a Pratchett-esque “wrangler” who asks the awkward questions that a five year-old might, and makes the observations that only someone with mild to serious OCD would feel compelled to express – “You can’t nail a leak, Prime Minister – you just get a bigger leak”.

Not failing to think – and executing the imperitives arising from thinking – is the key to a successful implementation. Period.

Oh, and it helps a lot if you can quickly understand the Client’s business way better than they do … really fast, and with an eye on what they are going to work out they want/need in two years time.

As for the metrics expressed – well, I’ve never had the luxury of knowing how many lines of code is going to be required before I knew how many hours away the completion point was required to be, so it’s never been important … trite, I know, but true nevertheless.

Russ

All so very very true

You get a 10 out of 10!

I have been developing software now for over 25 years and seen a lot of changes during my course. But one thing has always remained… bad programmers!

It has been my experience that the cultivation of good or bad programmers has always rested with management.

Good programmers come from management laying out solid development processes and holding everyone accountable.

Bad programmers come from management laying out a policy of “get it done no matter what”.

With that said I always believe that failure is from the top down…

J.R.

From Mil-Std-2167 to bringing the Customer on board. Standards and Specs don’t do it – being able to adapt to a customer’s constantly changing requirements, and stay within the budget and time line – does. You may think the latter is impossible – yes – but easier if you have the customer on board.

Many good points, but I’ve seen an interesting pattern concerning this one: ” Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems.” … Especially with RoR, the developers will take “existing solutions” to different but similar problems, and call it done. It also takes a bad programmer to be incapable of producing a solution but instead to rely entirely on the community. Combining a bunch of gems or plugins, then wrestling the customer into accepting functionality that doesn’t match their spec, and trying to sell what amounts to a Frankenstein of parts, is a VERY negative extreme. Arrogance is bad, but confidence is not. Some of us know a bad solution when we see one, when to reuse, when to rewrite, and when to say: “that cannot be done.”

You were not specific enough on that aspect. I hand n00bies code snippets daily because they are searching for “existing solutions to old problems” … they certainly aren’t “great programmers”. I was like them a LONG time ago, and have some compassion and enjoy helping. I just had to explain to one of these “great programmers” yesterday what a unix timestamp is.

Perhaps you should have changed: “find existing solutions to old problems” to “their minds themselves are libraries full of existing solutions to old problems or the places to find them”? Modular code is awesome, re-usability is elegance, but RoR type patchwork coding can quickly turn into Frankenstein which is neither awesome, nor elegant. A Master Programmer knows the difference.

Take this comment box, that pretends to be AJAX, but spirals forever on submit in Chrome. I know you are using Word Press, I use it too, but whichever comment plugin your using is apparently not as reliable as the default. At least not in Chrome. Gonna try to post in Firefox instead.

Ah hell, now I look like a fool for posting twice, but it’s because of the bad AJAX in this page, you look like a fool writing about good programming and having bad code on the page, and we both know that it’s really because you reused something that doesn’t really work very well. :-\ At least Word Press has a bazzillion other plugins you can TRY you good “programmer” you. Maybe one of them will work all the time instead of just some of the time? Get my point? The ability to hunt down and reuse something is often lazy in itself and an example of a lack of skillz not evidence of them. Just sayin.

Was just dying to see what this did in IE… “Error on page”, now to click Submit and see if it works… I would start firebug up and analyze the problem, but I’ve just now realized I’m the user just now. :-\

While the number of lines of code written per day may stay fairly constant, the amount of work done by a line of code goes up with higher level languages. 10 lines of C code does more than 10 lines of assembly. 10 lines of C# does more than 10 lines of C code. Thus productivity grows as the amount of work accomplished by a line of code increases with higher level languages. Also, one line of code today might call a library that does the work of 10,000 lines from twenty years ago. Kurtzweil estimates that the productivity of programmers doubles about every 7 years due to these and other effects. I know I get more real work done every day than I did twenty years ago. So it is not all bad news.

I disagree with a lot of this post, but I do agree that good programmers are WAY better than bad programmers.

I laid off a programmer (who was getting paid $140,000.00/year) for reasons to include he did not know how to redirect a program’s output into a file – his complaint was the stdout kept scrolling off the screen and he couldn’t read it. His code fell into the category of throw it away and rewrite. Another one would no let people look at his code because everyone who did would rewrite. After he was gone, we unlocked his directories, looked at his code, and rewrote it, in a fraction of the time he was taking.

However, both of the aforementioned gentlemen despite being bad programmers, still used some of the “great programmer” techniques. For example, they both practiced code reuse extensively, though I cannot imagine how they would program without being able to cut-n-paste….

I first programmed in 1965 on a Burroughs mainframe, 9.6k memory and no operating system, in machine code and assembler. I’d certainly agree that the amount of ‘work’ done by a line of code does increase the more powerful the language (and supporting operating systems/environments) , as I have lived through their development.

But leaving languages aside, the relative productivity of the programmers hasn’t changed over the years. Still have a top 5% you’d pick for the tough/critical jobs with a progression down the ranks. But given a large enough organisation, there are usually suitable tasks for most levels of programmers. Excepting those who would really be better of in an different career path.

45 years on, after being side tracked into business analysis, management and design, finally back to programming, my first love.

Profound thoughts , I agree with most of what you say.

@RussTheMan
I strongly agree ! Let “software engineering” practices (if any) be told by people writing code really… in other words, come back to real world. Practices are means, thinking and competence are the value. I only would add, as for great people, “be humble” and “listen to colleagues”, good may also be around you…

Excellent….. I’m agree with these points..

I disagree. EG The best greatest most experienced ninja embedded systems programmer would, if required to write a java database web interface be classed a ‘bad and unproductive’ programmer.

Great post. I especially like the points on entropics. It is a real challenge getting one of my clients to understand their software (previously written by others) is dead and unmaintainable. Now I have some better sound bites. Thanks!

I have only read the first few sentences of this article and couldn’t read beyond the sentence: “…….A programmer spends about 10-20% of his time writing code…..” The word I can’t get past “HIS”. I’m sure this is a very good article and the title definitely caught my attention and I will finish reading it. But please, for anyone reading my comment, especially authors, please remember there are female programmers out here too. Maybe I’m being overly PC but I see this a lot. Thanks.

I believe the best programmer is a lazy programmer (LP), as opposed to a lazya$$ programmer (LAP).
A LP doesn’t want to ever come back and do the same thing again.
A LAP doesn’t think about next week.
A LP reuses technology that is available to perform the job at hand.
A LAP cuts and pastes code.
A LP comments their code cuz they know they, or some other poor schmuck will be back someday.
A LAP could care less about how hard it is to understand a piece of code.
A LP bothers to organize existing code into a meaningful structure with recognizable patterns.
A LAP just adds another nested conditional expression.
A LP writes documentation to remember why the code was designed the way it was.
A LAP just sends an email saying ‘Done’.
A LP has plenty of time to listen to good code singing on it’s way thru the machine.
A LAP has plenty of time to point out why it’s somebody elses problem that the damn code don’t work.

Two Rules: Play nice, do your freekin job.

nuff said

@RussTheMan

One point about the user guide… in my days of gathering user requirements, I always found that if I wrote the user guide before I started my mental design, I had fewer changes to make during coding AND in the end, my programs really didn’t need a user guide.

If you liked this article, you’ll appreciate “The Mythical Man-Month” by Fred Brooks. A great book with lots of software development wisdom and lore. See a synopsis on Wikipedia.

I wholeheartedly agree with all of these points. Clarity of mind is the hallmark of a great programmer, in my opinion.

For a great programmer, the act of programming is almost ancillary to the most important thing: the thought process that brings one to a clear picture. Once the process is laid out in the mind, actual programming it is rudimentary.

@ Attila
Attila, Amen!
Here’s one of my stories: My Bachelors degree was in Psych and Education. I taught myself programming starting with Paradox in 1990 and by 1995, had reached Delphi with SQL and the BDE.

In 1998, I went to an interview at a phone company and the other guy with a computing degree and a better “corporate look” in his suit got the job. I took a three week vacation to Paris and other favorite places of mine. Five months later, my agent called me about the same phone company. The other guy had left after a fight with a female co-worker, and had not completed even the first project. It had an graphically elaborate first screen, though. The assistant manager had apparently liked him and she helped him design the screens. She knew Assembler.

I began on Monday, got permission to start programming the project from scratch, and finished it in _three_weeks_ without screen design help from the assistant manager. It was a pretty straight-forward database application written in Delphi on Windows to display a lot of Unix data collected from telephone switches. The user and manager loved it. They kept me on and renewed my contract two more times, for a total of one and a half years, until in 2000, all the contracts evaporated with the new U.S. Republican Government’s blessing of deregulation. All future contracts were sent to Russia and India for 10% of the normal salary.

It’s a wonder anything gets done at all!

The most elegant solutions will always be the simplest ones. You don’t have to write 10.000 lines of code to make it “elegant”, if you can get the same job done with 25 lines of code or a good iteration/loop.
So the amount of time spent on thinking about the program, in my opinion, is irrelevant, if it “just comes to you” how to write it, it’s like it’s in your blood. You are the damn code

@Laura Hi Laura, I respect your femininity, wanna have lunch? Anyways, Just one thing, does anyone find that programming is taxing, on your personality? When I was a kid, I loved coding and I couldn’t figure out why nobody seemed interested in the amazing discoveries I was making in my little world on a day to day basis, I learned assembler (Intel, AT&T sucks) because that was badass in IMHO then learned C/C++/Java/blablabla Anyway somewhere through learning all this stuff I realised that I was a nerd, I didn’t look like a nerd but I was. So I sought a little ballance. Ballance is a two sided thing, the geniuses I know (I know two) don’t have balance, like the article says they sleep and dream of solutions to their problems (as I used to) and thats what makes them brillient, total dedication. I have to force my mind to not constantly run computations in the background (if I have a problem, then halfway through the day a solution will pop into my mind and I’ll know that I was thinking about it the whole time) and because of this I’ll never be truely great. I’m holding back. But I’m ok with that, thats my choice, I have a 148 IQ and that should be enough for any employer. My question is: do any of you feel like me, like maybe your coding is taking a toll on your life, your time for living?
PS: here’s a link to using Direct3D 9 with C# and Visual Studio, it’s a beginners 3D tutorial with cool part on bump mapping and world creation. Hard to resist, you know you wanna make some 3D shit

In 30+ years of programming, designing and systems architecture I’ve met exactly 2 people who were great programmers.

They are extremely rare indeed.

I love it when someone puts something this critical and essential into such simple language. It means I can point my non technical friends here and they can start to “get it”. As far as my peers go, they can keep hearing this from me in a more technical fashion.

The only thing I do not completely agree with is the phrase, “find existing solutions to old problems”. I see my peers grab open source projects and try to get them to work for what they want; they spend days, eventually either giving up or settling for some hacky solution to make the open source “existing solution” work properly.

I always check for an “existing solution”, but I refuse to spend more than 5% of the time it would take me to code a solution myself, looking for an “existing solution”. And I refuse to spend more than 10% of the time it would take me to code a solution myself, trying to implement some pre-existing solution.

Happy Coding!

So simple and so true !!

I think that research is about changing randomly code and checking if it is working, cause Ya know, it wouldn’t be called research if we would know what are we doing.

Agree 100%! That’s why I heard some star programmers gets paid $1 million salary at silicon valley. It’s very much like professional sports, one man can make or break the team. I left most of my previous jobs because I cannot stand the entropic failure of spaghetti code written by some supposedly “experienced” programmers. Or some managers who think adding programmers to a project won’t slow down it even further. For me if the code is not beautiful, then it’s not worthy.

Is anything worth thinking about 24/7?

Good programmers write unit tests as they code. They rely on their unit tests to guide the implementation of the design and leverage them to minimize code rot and bugs. Bad programmers see unit tests as a waste of time. They are more than just less-productive, they waste everyone else’s time by writing code full of trivial defects and is near to impossible to change/refactor (due to lack of unit tests). Bad programmers fear their own code since deep down inside, they know how brittlely/poorly it was designed and implemented.

I need to stop thinking about this, since this has hit a bit too close to home with what I have to deal with.

Lots of truth here, although I think that

“Most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level” and “A great programmer is 20-100 times more productive than the average.”

are somewhat contradictory. You can hardly be 100 times more productive that an average programmer without writing significantly more lines, no matter how expressive code you write.

“Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. ”

I thought it was just me, but I have solved some very complex programming in the shower. I wonder why that is?

The shower acts as “brain cooling” and allows you to compute more efficiently

@ CJ

We have one programmer here who does unit tests… since his first day. But, after a few weeks he stopped. Why? we’ve got deadlines to meet.

Like, how do we do TDD/unit testing if the business rule(s) to code changes frequently?

For our personal projects who does not have strict deadlines, yes we do. But as an employee, we are paid around 90% producing, and the remaining is what’s left for testing.

I code better when drunk. Anyone else?

Very very True, and a programmer can know it better then anyone.

Except 1 point “most programmers write about 10-12 lines of code per day that goes into the final product”, it all depends on what you are developing, if its a R & D or highly performance related then yes. As of me when i have something new to develop or a big change I code for almost first 3-4 hours in my day without even looking at the end result( just visualizing the end result in the mind), its only in the last 1 hour of my work that i run my code and fill in the gaps if any

@Clarkson
“Is anything worth thinking about 24/7?”
90% of the time never. but sometime when we have something very complicated on hand yes we do, infact most of the solution to such problem come to mind when we are away from desk

@Anon
Lolz, I can only name by Delivery manager in that category.
Seems like ur company must have made drinking elgal for ya

@ Kelly
The work done by the code is directly related to the design of the code. A “line” of code is not an instruction, but a complex construct, even in assembly. If you add macros, use libraries, and so on, assembly can be very powerful as well.

The language is just one of the obstacles you have in the path to generate a program. Each language has strengths and weaknesses. C is great for some things, PASCAL for others, Lisp or small talk for still others. Choosing a language is part of the design process. Using C or PASCAL to process matrix math code is a poor choice while Fortran or APL is better in that area. Writing reports in APL is miserable (unless you have precreated some good libraries) so COBOL, SNOBOL or JAVA might be better for that. Managing large quantities of data might be better done in a database, or possibly (for somewhat smaller datasets) a spreadsheet.

So the choice of platform will make a difference as well as understanding the requirements, the necessary interface and the context of the data.

I’ve been programming for many years, yet every day I learn something new, from modern memory management to the different ways data can be represented to the implementation of a more lively interface with 3d or mechanical feedback.

I don’t remember who said it, but the only constant is the rate of change. FAST!!

This is no doubt true for some cases, I currently have a couple of the bad programmers working for me, but they have there place! The code is not amazing, but it works, and it makes money. In your perfect world we all have 90% of our day to sit on our asses reading documents explaining things you should just find out for yourself, in the real world we have to make money and you do that by writing code. People who write articles, and papers and examples for you to read learn by doing. They sit there coding 90% of the time, then they take the bits that work well and use them, and bin the rest.

Plus, you’re talking about application development, web development is a whole other ballgame. Try sitting reading w3c documents for 7 hours a day and see how fast you get fired.

Good programmers spend their time developing software and creating solutions for customers and stakeholders. Bad programmers write articles about “bad programmers” using spaghetti PHP code written by bad programmers.

foreach (qw{wordpress joomla drupal}) {
print “${_} sucks!\n”;
}

Nice. I’ve always been aware of the content of this great book, but have been to cheap to buy it and read it in it’s entirety.

Also, great posts, I whole heartedly agree with most of the posts. And yes, I do make some great connections after a few brews (google xkcd ballmer peak, it’s true to and a great lol) and I do make great connections in the shower, or those few moments between when the alarm clock tells me to wake up and my body actually acknowledges it. But I think that explains the complexity of what we are dealing with. If I’m just thrown a problem and need to solve it immediately (something business things I can do with enough overtime) I put in more time re-writing all the damage I have done. If given a night to sleep on the problem, completely comprehend it, let my brain stick each piece in the right spot and wait for natural processes to sort it out, I typically end up with the best, most concise and scalable code and I love it when plans come together like that (yeah, a bit of a re-work from my childhood heroes on the A-Team, please don’t hate me for that.)
Also, I don’t think there are terrible programmers out there. There are just many that are inexperienced or come to the wrong conclusion because most college B.S. degrees are just that. I have met many programmers that were faster than me and had a higher level of quality… if I diagrammed or documented exactly what they should write, expalined what control and data structures to use, how to organize the code, etc.. The big failing is that given a set of requirements and having to start from scratch, they do not have the first idea how to proceed. I guess I’m lucky in the fact that I started writing code at 8 and was struggling with what I would later learn were the “classic” problems described by Knuth and all at a young age. Most 4 year college programs do not give enough exposure to programming to understand the basics, let alone where the problems inherant to any program design truly start. That can only be arrived at through experience and a lot of frustration.
I think the problem has two tails, one is managements convuluted misunderstanding of what we do, and another is to tear into less experienced programmers instead of bringing them up to a higher level through interaction, good discussion, example, and sometimes hard learned lessons. It’s not that mistakes were made, the important thing is that do we understand those mistakes enough so we will not repeat them.
I see these problems rise up daily at work, but that doesn’t mean management is too stupid to learn from these mistakes. The problem is sometimes the corporate environment is to rigid to yield for this. There was a hilarious article (or joke) on delicious that I wish I bookmarked, but it is so true. I walked into a company that was Waterfall over a year ago, and since I have been there the scope and level of detail desired quickly outpaced what was the norm there, which was simply adding to existing functionality. After a year of working as Sr Dev on projects with scope much larger than the company had dealt with since the sites first launch (which was actually written by external consultants with no impact internally) that had moving requirements (60 re-writes on my last project after “development started”, which made the project one month overdue (2 months if we didn’t pull epic overtime) in a lessons learned exercise the business didn’t fault us and agreed to try a more agile model.
Now I am on a new, experimental team doing agile with short iterations, small teams, daily scrums, fast turn around. Almost there. This is why I wish I bookmarked that delicious link, because it made me laugh because this situation is the same. For all the agile talk going around, they still won’t give up on the basics of waterfall. So right now I feel my projects are at a higher risk than either. I go through a fast 15 day agile cycle, yet still have QA come in on day ten to start whining that something is 2px off in firefox and BAT at day 15 (the day I am supposed to go live). In the last BAT cycle, they realized they gave my team the wrong requirements, forcing a week long re-write which pushed the next development piece up by a week, and who looks like the idiot here. Me I guess, but it’s not really that bad. Any decent business wants improvement, and if you can explain it and quantify it in any measurable metric at all, you will find people willing to listen and learn. That’s another complaint I constantly hear, about how the business just doesn’t get it. But they get numbers, they get results. Coding is an experiment in a lot of ways, but the process for doing that is the same. We’ll never find a one size fits all solution, but we can find ways to recognize what kind of app we are creating, pick the best process, guide business and show them quantifiable results, and help raise the level of less experienced programmers that are involved in the process. Win-Win.

Oh man, this is so true, I thought I was one of the few (if not the only one) that spent an hour, if not longer, thinking about coding in the shower. I’ve been really temped to install some kind of waterproof whiteboard on one side of it so I can jot down notes haha.

Couldn’t agree more – I’ve done so much PHP and my clients are always like? Well isn’t it easier to do this and that?! DO IT YOURSELF THEN CLOWNS!!

Actually what you describe is the difference between a software engineer and a programmer. Programmers program. Engineers problem solve.

@ Laura

I think this stems from many languages giving words genders not only based on if the word is a human name or not. For example in my country we say “she the computer” when directly translated and “she the police”, of course those words don´t come out like that when spoken in my home language and when translated into proper English we just say/write “it” when making a reference to a computer or the police, and in the same way in my country we say “he the programmer” just because of the way the word is structured and pronounced and this is a habit that tends to arise when writing in English, of course there should be written “it” when there is a reference to the programmer in the article however you can´t get so defensive because of such a simple mistake.

Oh and I´m sorry if my comment is too late to be valid or if I´m getting off topic, I don´t frequent these forums, just found this with stumble and wanted to add this comment.

This is pretty technical stuff for me, but being an online university student and an aspiring entrepreneur, I need to learn more about this stuff. Thanks for the opportunity. Have any of you read “Programming and Meta-programming in the Human Bio-Computer” by John C. Lilly? … or “The Human Edge: Information Technology and Helping People” – edited by Gunther R. Geiss and Narayan Viswanathan?

While I agree in general with this article. It is only restating things we have known for 30 odd years.

And it has left out a couple of very important things.

Productivity is improving for a number of reasons – even though we still code about the same number of lines each day. One important reasons is the computer languages are better, or lead us to better programming styles. Object oriented programming has dramtically altered how we think about building programs.

Another is an accumulation of good software libraries. eg when I started programming we didn’t have DBMSs and had to code B-Trees etc just to get started.

And the main cause for failure is, imho, a view by management that all programmers are equal combined with a corresponding inability to recognise just what was the technically hard part of the project.

Training, commitment, experience – all essential for the good programmer. Add a touch of insanity and failed personal life for the great programmers.

Lot’s of good points here. I would argue that a leading factor in setting a programmer apart from his/her peers is the quality of their unit testing. The good ones have very few bugs…most of the issues returned should come from poor or unclear documentation.

These are really well said facts about programming. I agree 100% with what you said, and can confirm that most of my lines of code are “written” while in the shower or while sleeping. I wish everyone would understand these points because most people I know are ignorant about all this.

This is a great post. Being relatively new to programming it’s always interesting to read the advice of more experience programmers. I’d like to think I’ll be able to emulate some of these truths as I continue my programming education.

I just spent an entire day fixing a bad programmer’s work…

This post should be written into programming 101