Depression and the Software Developer (part 3)

(This is a continuation from part 2 of “Depression and the Software Developer”.)

[Note: This is a recounting of an experience from several years ago. Read the story from the beginning in order to catch up.]

According to psychologist Joe Griffin, the cycle of depression starts when innate needs are not being met. Among these are a sense of achievement and knowing that we are valuable to others. Setbacks like this, however, are just a part of life. What turns setbacks into depression is when they dominate one’s thoughts, they overwhelm him, and he loses hope.

Unfortunately, if my previous work situation epitomized camaraderie, this one did the opposite: Continue reading

Posted in Uncategorized | Tagged , , , , | 4 Comments

Depression and the Software Developer (part 2)

(This is a continuation from part 1 of “Depression and the Software Developer”.)

If one of the most powerful weapons against depression is hope, one of its most powerful fuels is hopelessness.

I attacked my next job with gusto and enthusiasm. The company had previously outsourced a project to an offshore contractor, and now that the fit had hit the shan, they were looking to bring it back in-house. The product was a stand-alone box with embedded software, and they hired me to take over the hardware diagnostics, which are used to ensure that the units sent to customers actually work.

Somewhere, I read that it takes six months for a new employee to become situated in a new job. But I did it in four. And then I crashed. Hard. Continue reading

Posted in Uncategorized | Tagged , , | 1 Comment

Depression and the Software Developer

Motivation: It's not that I'm lazy; it's just that I don't care.

Knowing what I know now, I wonder how I avoided depression for as long as I did:

  1. Stress causes depression.
  2. Perfectionists are more prone to depression.
  3. Isolation reinforces depression.

As a software developer, those frequently go along with the job description. Seasonal Affective Disorder has gotten the rap for at least some of the funk, because many software guys spend most of their time indoors, duty-bound to their office chairs. But surely SAD can’t take all the blame. Long hours of solitary work in front of a computer screen, the amateurish demands of tech-heads-turned-managers, the over-constrained projects, the intolerance we have toward bugs, the widespread myth that software is “free,” and (most importantly) how we as developers respond to these pressures, all these must take some share of the blame for developers’ depression. Continue reading

Posted in Uncategorized | Tagged , , | 7 Comments

Software Bugs, Crawling Everywhere

Software developers have a wonderful explanation for why there are so, so many software bugs. Unfortunately, it’s a highly technical explanation that’s very difficult for the layman to understand. I’ll try to summarize, but be aware that the following is a gross oversimplification.

The root problem is that software is complex. And it’s not just that software has complexity. It has a lot of complexity. And there are different kinds of complexity. For example, there’s necessary complexity and unnecessary complexity, architectural complexity, design complexity, protocol complexity, and API complexity. And then you have process complexity, such as whether you are able to deliver working software or whether you blame your manager and call him a dork.

Needless to say, software developers like to blame bugs on the complexity of software–or on their managers–but mostly on the complexity of software. However, that’s only part of the real cause of software bugs. Software developers have a dirty little secret: most bugs are simply caused by simple human error, and many of these can be prevented. Continue reading

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Too Late, the Code Is Already Written

One way to deal with poor communication on a software project is simply to ignore the people around you and do what you wanted to do anyhow. Of course, this strategy can backfire, especially if you don’t know what you’re doing. But in that case, you probably won’t know enough to notice it backfiring, so it will all work out in the end.

That’s what I did at my first job. Continue reading

Posted in Uncategorized | Tagged , , , , | Leave a comment

Top 10 Most Bizarre Programming Languages Ever Created

From NETTUTS, a humorous summary of 10 bizarre programming languages, namely:

  1. Ook!
  2. Piet
  3. Whitespace
  4. LOLCODE
  5. Shakespeare
  6. Befunge
  7. reMorse
  8. FALSE
  9. Whenever
  10. l33t

The conclusion one draws from this list is unmistakable and undeniable: There are programmers in the world who have far too much free time on their hands!

-TimK

Posted in Uncategorized | Tagged , | Leave a comment

More Reasons to Avoid SourceSafe

I’m helping out with a project I used to work on, one in an organization that uses SourceSafe to manage its source code. Fortunately, this time, I don’t have to deal with SourceSafe this time. All I have to do is to submit my diffs against a baseline, and someone else will have to deal with merging them into the repository.

On a more recent project, we’ve been using git. There’s no comparison. It’s pretty cool how git effortlessly handles situations that SourceSafe can’t even fathom. (Another good alternative is svn, but using svnmerge on all branches.)

Over 2 years ago, I posted a list of reasons to abandon SourceSafe. Now, since I’m hacking with Microsoft Visual Studio again on this project, I happened to run across another web page listing even more reasons why you should abandon SourceSafe as quickly as possible.

Chuckle, chuckle. Thank God that I don’t need to touch it.

-TimK

Posted in Uncategorized | Tagged , , | Leave a comment

Proof That Programming Language Trivia Is Stupid

As reported in the New York Times:

When older people can no longer remember names at a cocktail party, they tend to think that their brainpower is declining. But a growing number of studies suggest that this assumption is often wrong.

Instead, the research finds, the aging brain is simply taking in more data and trying to sift through a clutter of information, often to its long-term benefit.

This makes sense.

The myth is that humans use only a fraction of their brains. In truth, however, fMRI’s and other tests observe neurons firing across the entire brain (when we use it). And when one area of the brain grows–in order to get better at one particular kind of thought process–it must steal neurons from the neighboring regions. Different parts of the brain are always competing with each other for space.

Now, I’ve been saying that I don’t memorize details of programming languages that I can look up in 30 seconds on the Internet. Yes, I can do Perl programming, Javascript, Java, CSS, and many others. But don’t give me any off-the-cuff language quizzes. They’re stupid. Like Sherlock Holmes, I have emptied my mind of insignificant facts, in order to make room for the important ones. I can help you design great software, but language trivia is for newbies.

It seems Sherlock and I were right.

UPDATE: It seems Google has discovered, through measuring their job interviews, brain teasers and test scores are useless at determining whether someone will be a good developer. If you want to tell whether a prospective developer will write good code and fit in with your process—and if you want him to be able to tell, too—forget the traditional interview process. Forget sitting across a table from him and asking him to read and write code on a whiteboard. If you want to tell whether he’ll be a good developer and a good fit, spend an hour pair-programming with him.

-TimK

P.S. Actually, programming language trivia may not be stupid, because some old-time developers dedicate themselves to such things. But having wrapped themselves in the details, they tend to be weak on engineering concepts, especially new techniques to develop bigger software better and new practices to develop software faster and more reliably.

Posted in Uncategorized | Tagged , | 1 Comment

You Know You’re an Old Fogey Software Engineer When…

Today, I came to a realization. I’m now officially an Old Fogey Software Engineer. You know, like those narrow-minded, intolerant, old-time veterans of the field I used to look down on when I was but a young Whippersnapper. They were so limited in their view, only being able to do what they have always done, always disagreeing with me, always putting roadblocks in my way, always wiping out my carefully crafted abstractions in favor of in-line code, always throwing out my object-oriented design in favor of procedural, always turning my portable, reusable code into use-once code. I never stopped to think that their objections might have been born from decades of experience and life-long expertise.

Now that I’m officially on the other side of the fence, I’ve discovered a new rule: When your junior colleague thinks his fancy object-oriented code is simpler than your straightforward procedural code, you know it’s time to raise your rates. Because they’re not listening to you, so you know you can’t be charging them enough. Continue reading

Posted in Uncategorized | Tagged | 10 Comments

Does Bad Writing Reflect Poor Programming Skills?

Writing is a communication skill. And they say that communication skills and the other soft skills are what programmers need today. Effective developers don’t work alone. They work with others in a team. And a team member needs to communicate with the other team members to be effective.

It’s like playing football. No one person can win the game on his own. Each player does his part to determine whether the team moves forward. The center snaps the ball to the quarterback, who hands it off to the half-back, who runs through a hole the offensive line has created in the the other team’s defenses. Or maybe the quarterback passes the ball to a receiver. Occasionally, the receiver is on a different page than the quarterback, and when the ball is thrown, there’s no one there to catch it. The play falls apart. Players either work together, or they lose the game. In football speak, this is called “not executing well.”

Continue reading

Posted in Uncategorized | Tagged , , , | 65 Comments