Smash Company Splash Image

September 15th, 2010

In Technology

4 Comments

Do web designers and programmers just stop caring after awhile?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

I start working at a new place. There are 2 programmers that have been working there awhile. I look at their code. It is atrocious. I am left to wonder if they care at all what another programmer might think of their work.

A friend of mine starts working at a web design shop. Many of the programmers who are there have been there for 3 or 4 years. They are in the habit of cranking out bad code at a fast rate. Whatever spark of creativity they may have once had, it has been worn away by projects that are forever behind schedule. Their project manager encourages them to cut corners and go faster. Do they still care what another programmer might think of their work?

I take over an old website that was built by another programmer. Perhaps they were experimenting with new ideas when they created the site. The code is an unusual mix of objects and procedural code. Configuration information is stored in several locations – sometimes in ini files, sometimes in PHP “config.php” files, sometimes declared as global variables, sometimes as constants, sometimes hard-coded as initial values to object variables. Did this programmer care what another programmer might think?

A friend takes over the maintenance of a well known political web site. He finds that the original programmer had been learning programming and PHP as they built the site. Apparently unsure how to use functions, the original programmer initially triggered blocks of code by putting the code in separate files and then including() the file when necessary. That original programmer ran the site for 2 years, and over time clearly learned a lot about programming. The later code is better written, but the original code is still there. This programmer then moved on to better things, perhaps bored or looking for better pay. They did not bother to clean up the work. I’m asked to help out. The code is so bad that my friend and I trade snippets back and forth, laughing as we go.

1 year later. By a very strange coincidence, this same friend of mine takes over another site, focused on astrology, which just happens to have been built by the same programmer who built the political website. Now we see many of the same bad programming, including some bits of bad code that were apparently copied from the political website. To give an example: the original programmer decided to store some data in one database, and some data in another database. To switch between the 2 databases, the programmer had put database connection info in different config.php files, and then the code includes these different config files at different times. Some blocks of code actually go back and forth between the 2 databases, 3 or 4 times in the space of 30 lines. Most of the time the code is connecting to the database as the root user, so if the username/password was ever compromised, an intruder would have full rights to everything. We are now looking at code that this programmer wrote 4 years into their career as a programmer. They seem to have never cared what another programmer might have thought of their work.

I start working at a new place. I am told to talk to a programmer named John. He has worked at this company for 4 years, and he was the lead programmer for most of that time. He was hired to save the company. My co-workers speak of him reverently. They recall the way, during his first year, he would work 60 hours a week. They recall how he would gently chide them for writing bad code. They recall how many good articles about programming that he got them to read. Before John there had been another lead programmer, named Ben, who had what is described as “anger management issues”. Ben had been a terrible programmer, and John had seemed like a saint in comparison. But now John is leaving the company. During his first 2 years he tried to educate management about workflow issues in the company, and how they effected the tech team, but now he no longer fights such battles. He and his wife have bought a farm up in Maine. He spends most of his time there and he works remotely. It is hard to get a hold of him. He is working only part-time now. I look at some of the code he has recently written, and this code contains some bad anti-patterns, such as methods that contain 400 lines of code, and methods that have SQL hard-coded in them. After a month of working with him, I get the sense that he is a bit burned out. Does he care much what I might think of the code he is writing nowadays?

I think it is a pattern: the more programmers or web designers are at one place (or the more they work alone) the less they seem to care about the craftsmanship of their work. I wonder how places like Google and Facebook deal with the potential for burnout among their staff? I imagine it helps to have a management team that understands technical work. And I can imagine that being around other highly motivated folks probably helps. Possibly a constant inflow of new staff is necessary, otherwise even the best companies would settle into a stagnant state.

Source



Check out my book:





RECENT COMMENTS

July 15, 2018 3:17 pm

From Anonymous on Friendly, intelligent flash cards?

"Good to know that I wasn't too late :)..."

July 15, 2018 8:32 am

From lawrence on Friendly, intelligent flash cards?

"Thank you for these comments regarding Anki. It sounds useful. I can imagine having the full context of the se..."

July 15, 2018 6:32 am

From Anonymous on Friendly, intelligent flash cards?

"Anki limits how much you review. I have 10000+ cards across my decks but the program arranges them in such a w..."

July 6, 2018 3:42 pm

From lawrence on Docker is the dangerous gamble which we will regret

"RK, your comment is irresponsible and pure FUD. These technologies are not being deprecated. Some of them have..."

July 5, 2018 10:21 am

From RK on Docker is the dangerous gamble which we will regret

"Deprecation warning: The Packer, Artifact Registry and Terraform Enterprise (Legacy) features of Atlas will no..."

June 25, 2018 11:58 am

From Barry Jones on Docker is the dangerous gamble which we will regret

"Solid read. I will say that it seems like there is a lot of momentum growing around Ansible these days. It see..."

June 21, 2018 11:25 pm

From Anon on Docker is the dangerous gamble which we will regret

"Thank you for this. Sometimes I feel like I'm living in a bizarre, pro-Docker for everything world. I am prima..."

May 30, 2018 4:35 pm

From Thomas on Docker is the dangerous gamble which we will regret

"Thank you for this beautifully written and relevant piece. I think it has saved me a whole world of pain. ..."

May 29, 2018 10:46 am

From lawrence on Docker is the dangerous gamble which we will regret

"Andrew Reilly, thank you for writing. You make several good points, especially this: "Also an extra layer o..."

May 28, 2018 11:17 pm

From Andrew Reilly on Docker is the dangerous gamble which we will regret

"Nice article, thanks! I think that it's interesting to also look around at the problem from a greater dista..."

May 21, 2018 2:39 am

From xulin on Docker is the dangerous gamble which we will regret

"Elixir & Erlang..."

May 16, 2018 3:28 pm

From Steffen on Docker is the dangerous gamble which we will regret

"I'll never regret the use of docker cause I never used it (and never will). My advise is the the anti docker ..."

May 15, 2018 1:36 pm

From Clayton Gulick on Docker is the dangerous gamble which we will regret

"Great article. The current Docker craze, imho, is the same old problem where engineers get a hammer and every ..."

May 15, 2018 10:38 am

From lawrence on Docker is the dangerous gamble which we will regret

"Yawar, yes, I have looked at Elixir. And as I mentioned in the article: "They are now examining Go and E..."

May 15, 2018 10:32 am

From lawrence on Docker protects a programming paradigm that we should get rid of

"Agam Brahma, thank you. I have now fixed the typo...."

4 COMMENTS

September 16, 2010
10:06 am

By Colin Steele

In my experience, over time, programmers will self-select themselves into the group you’ve identified here, which we might call “programmers in practice”, or “de facto programmers”, and another group: “craftsmen”.

(Pardon the non-inclusive language. :)

I have enjoyed the privilege of working with many more in the latter group in my career, although not without exceptions. Over time, I’ve observed a few things about the group of programmer-craftsmen, including that over time, the programmer-craftsmen cares MORE deeply about their work, not less.

September 16, 2010
11:01 am

By lawrence

Colin, thank you for writing. I am not 100% sure I understand what you mean. In my last paragraph I tried to suggest things that help programmers avoid burnout. Do you feel that the group you identify as “craftsmen” is sort of naturally immune to burnout?

I agree there are many programmers who care more deeply about their work as time goes by, though I imagine this is also a group that seeks out those challenges that keep them interested in the work.

September 22, 2010
9:12 pm

By Colin Steele

While I don’t think that craftsmen are *immune* to burnout, I think that they self-select out of situations in which other programmers become burned out. That might be by choosing projects (main or side), choosing the right (or a different) company, or by continuously challenging themselves. I think anyone can get burned out, but the top performers bail out and move on before they fall victim. Or they preemptively avoid situations like that altogether.

The point I was making is that in my experience, the group you describe can be contrasted with folks who exhibit the exact opposite trajectory. Those are the ones I like to hire, and work with!!

September 23, 2010
10:42 am

By lawrence

Colin, I like the way you put it:

“I think that they self-select out of situations in which other programmers become burned out.”

I think you are right about that. That’s the key thing, really, taking steps to avoid burnout, and preemptively leaving situations that would lead to it.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>