In several situations in my development career, I’ve been faced with creating something huge from nothing with only a basic understanding of the given programming language.
When I look back now, half the problem was my agreeing I could do them in the first place. My management would tell me to do what I could, and I was very eager to both dive into the language and accomplish something substantial. I never refused a project. I always grossly underestimated the time to complete.
The problem was this. How do you build something bigger than your personal experience? Sure, you learn as you go. But think about that. To learn something well, I mean well enough to use as a good solid building block in a complex system, you have to gain experience with it.
There’s no time for that. To take the time for solid understanding of each technology used in that huge complex thing you’re building is to bring the ire of management. “You’re not even typing, you’re always just sitting there reading.”
What choices did I have? I did what I could. To get things to work at all, I used Stack Overflow in precisely the manner that infuriates seasoned programmers, namely copying and pasting code examples into my production project without completely understanding its fundamentals.
Any guilt over this kind of behavior can quickly be dispelled at the time by telling myself that I’ll come back and understand it later. At one point, in order to make an I/O interface work I resorted to adding a half-second sleep to the data read call, having absolutely NO IDEA why a delay made it work. Duct tape.
With the last huge thing I built, the barely-understood technologies were stacked three or four layers deep. It’s no wonder that the finished product was less than reliable.
I no longer believe in rumination and regret if it isn’t accompanied by hard-knock lessons learned, so to turn this experience into something less traumatic I need to outline just how I should have done things differently, as I’ve mentioned earlier on this blog.
– Don’t skip the crawling and walking and try to run out of the delivery room. Learn the basics, as painful and tedious as that is. Reverse engineering and example code might give you a general idea how something works, but it can’t show WHY they are done the way they are (unless they are commented in extraordinary detail). If management balks at the time you’re taking to learn, you have a management problem. No one with little experience can be expected to pull off a big project in the same time it takes an experienced developer.
– Have enough confidence in yourself as a developer to look your manager in the eyes and tell them that it’s gotten complicated and it’s going to take time. When you fail to do this, you’re painting a false picture of how hard you are working. Your management might either assume you’re not a productive developer or you’re not very bright. Or both. So much of software work now involves brand new technology that learning and applying things from scratch is really an unavoidable part of it. Whenever I’ve told my management that I’m trying to get a handle on something complicated, their response is to try to do something about it, like call in outside help (yeah, right, they need to read Mythical Man-Month). In the end, though, I’ve still had to grasp it for myself by my own means.
– Don’t overplay the “underdog” drama. If it were a movie script, little old me would build a spectacular piece of software on time without help and it would save the company. Seriously, my management has made the worst movie audience ev-ar.
– Don’t be afraid to tell your boss you’re having trouble. A good manager is there to REMOVE the obstacles in your path, to allow you to do your best work. When the obstacle can’t be removed, at least they will have a realistic picture of how your schedule will be affected. You have to try harder to MAKE your management understand what is taking the time. (That’s where sales experience would come in handy.) If you’re resisting this conversation, it’s possible that you’re avoiding one or more solutions to the issue that make you uncomfortable. For instance, one solution might be to give your project to a more experienced developer, and have you write the docs for it.
There is a LOT of psychology going on with me in software development, and I suppose it’s a similar psychology to what artists and other creative workers deal with. I’d like to explore the subject, not only for myself but for other developers who constantly beat themselves up without understanding why.