programming

JavaScript is More Complex and Important than You Realize

April 19, 2011

Kudos to Michael Woloszynowicz for pointing out that the JavaScript experience on the resumes of most people is worthless. If you tried to interview most people on JavaScript beyond the basic stuff, it would be a one-sided monologue. To be fair, these developers are much better at the language they consider their primary one and JavaScript […]

Read the full article →

Refactoring is Not About Reducing Code

April 18, 2011

The first introduction to refactoring for many programmers comes when a senior developer on the team takes a look at what they have written, yells some expletives and starts deleting blocks of code that has probably taken them days to write. After a few such incidents, these programmers start understanding what DRY means. Unfortunately, some […]

Read the full article →

Software for Multiple Customers

January 31, 2011

To follow up on my previous post about fully flexible software, I wrote about projects with a single customer or at least one entity that pays the bill and dictates the requirements. That is, of course, only one type of project, even if it arguably is a huge chunk of the programming market, including consulting […]

Read the full article →

Fully Flexible Software

January 27, 2011

A commenter (Daniel) on my previous post had this to say [summarized from multiple comments]: if you assume that requirements can be well defined and are static for the lifetime of the product, then programming is trivial. I’ve never seen this assumption to be true. […] at the level of programming, what do you have to […]

Read the full article →

Get a Better Word for Software “Craftsman”

January 26, 2011

Ade Oshineye complains that proponents of Software Craftsmanship misunderstand it: Ill-informed proponents of Software Craftsmanship tend to make the following mistakes: they don’t read anything except the manifesto and a smattering of blog posts. […] they focus on how Software Craftsmanship can benefit masters rather than apprentices. they think that signing the manifesto is the most […]

Read the full article →

Programming is Easy, Software Development is Hard

January 23, 2011

David Brooks has a great essay on which skills are difficult to master: She’s protecting them from the most intellectually demanding activities because she doesn’t understand what’s cognitively difficult and what isn’t. Practicing a piece of music for four hours requires focused attention, but it is nowhere near as cognitively demanding as a sleepover with 14-year-old […]

Read the full article →

Programmers and Micromanaging

January 17, 2011

Everybody hates managers who are fond of micro-managing. I suppose even the micro-managers realize this to some extent. So why do they keep doing it and not leave the rest of us alone? Well, one reason is that in the short run, Bad programmers exhibit better quality and productivity if they are micro-managed. While good programmers […]

Read the full article →

Writing Good Code

January 8, 2011

Randall Munroe (of XKCD) has a nice take on writing good code: Of course, this is an over-simplification, but it is true that if you set out simply trying to write perfect code, you will never reach there. The achievable target is succeeding in meeting your requirements with a reasonable level of quality, which is […]

Read the full article →

Characteristics of Great Programmers

September 27, 2010

David Veksle does an excellent job of describing them: A programmer spends about 10–20% of his time writing code, and most programmers write about 10–12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find […]

Read the full article →

When is It Good Enough?

November 29, 2009

Anecdotes are dangerous. Scott Koon has one about fixing a doorknob, linking it to the now-infamous Spolksy duct-tape programmer post and writes: Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW […]

Read the full article →

← Previous Entries

Next Entries →