Do as I say, not as I do.
I’m a normal, everyday web developer, and I have some of the same good and bad habits as the rest of you. I really do try to write beautiful, readable code as much as possible. But I’m also a one-developer shop in an organization that pushes the limits of what one developer can do in a given year.
It’s a perfect situation for me. I love the pressure, I love the work, and I love producing stuff that people actually use. It’s satisfying on a level that no other job I’ve worked has been.
The flipside to it all is that I find myself working on a dozen projects at the same time. Some of them are small, half-day development jobs. Others are six-month full-blown web apps using half a dozen different technologies. Some of those technologies are new to me at any given time.
Experimentation
Because my day-to-day development process almost always includes something new, I find myself doing a lot of experimentation, or, to make it sound more worthy of being paid, research and development. This is sometimes hard to explain to others. I feel like, eventually, I’ll be asked, “You don’t know everything you need to know to do your job? You need to sometimes google it or look it up in the API docs?”
Yep. No developer knows everything. The best developers admit that to themselves and go learn it. The worst of us say, ‘That can’t be done, based on my skillset’ and never take their work to the next level.
The Pitfalls of Being Intellectually Curious
While I enjoy the heck out of writing code flat out from memory – not having to refer to API docs, Google, etc. – and producing quality code in the process, what I really thrive on is being tossed a project with some aspect that I’ve never dealt with before. Even more, I completely love it if the project is a quick one, that’ll produce immediate results, make internal/external clients happy, and be quickly adopted for its intended purpose.
The problem is, because I love learning new stuff, and because I’m guilty of following the shiny thing too often, I end up writing a lot of experimental code.
I define experimental code like this: It’s code you slap together, without comments, sometimes without worrying about formatting… Code you never expect to go into production, but just throw together to prove a point. If you’ve never done this, I commend you.
It’s code you never expect will make it into production, but because you spent the time proving the point, and because you know you don’t really have the time to completely refactor it, it’s probably going to make it into production, especially if you’re a small dev shop.
Don’t Practice Bad Habits
If it weren’t for the learning and experimenting, finding new solutions and acquiring new skills, I’d find development a bore, and very quickly I’d assume my employer would get frustrated that we aren’t taking advantage of new, good technology to solve problems. It’d really just be the same thing every day, not much different from working on an assembly line.
But if experimenting comes at a high cost, then we’re doing it wrong.
The high cost of experimenting and learning new technologies comes when we write code that only proves a concept, and isn’t even close to usable in a production environment.
So I propose… Experiment, but take the time to write something that is at least remotely production-ready. Doesn’t have to be perfect, but completely sloppy (yes, I promise some of my code is completely sloppy so I’m not judging) is not good for anyone.
You might just stumble upon the perfect solution, so you might as well write it as close to right from the beginning.
Top comments (1)
Writing good code is a craft, which can be improved by repetition. The more you practice it, the easier it will be to write production-ready code, even when "prototyping".
I found that coding kata's or koans are both nice ways how to improve your code craftsmanship.