I started working as a Web developer few months back. Previously, I had no prior professional experience in programming besides school classes and fun-side projects I did on my own.
I am the only person there that really know how to code. I’m a fast learner and I know I can make a lot of stuff from PHP and JavaScript/jQuery. This was my background, and now I want to explain what I do at the company.
I work on a number of projects, and as I can tell from my company’s portfolio, which they have never had experience working with. Such as modifying their basic CMS to the extreme where it exhaust its functionality or working with vast amounts of data given to us in form of XML or JSON. So this was my practice, and I learned much and was awesome. But here are my problems…
As their main Web developer I’m constantly being under a time constraint which the boss isn’t bad about; he knows I’m learning… The problem is that when I’m under a time constraint, and I’m constantly asked to create custom modules or code that I had little knowledge before. I tend to make shortcuts, such as not following proper coding practices. I’m not talking about security, but common OOP, or structure code. I make the code work in as little time as I got.
How bad is this? I know it’s very bad practice to rush, but I don’t have much choice… How do I avoid this? I have little time to study on my own time, and I never know what next project might require, so I can’t prepare myself…
Any idea and tips on this topic are really appreciated…
7
This is basically long-term vs. short-term choice.
-
You may implement a feature in an hour doing dirty hacks,
-
Or you may spend the next week studying the actual needs of the users/your boss, translate them into requirements, refactor the code to accommodate the code base for the new change, write tests, implement the changes and document the new code.
The week minus one hour you gain immediately has a long-term cost. It costs money every time somebody (or you in six months) has to read the code. It costs money when something breaks, and nobody can find the reason of the issue. It costs money when you need to implement new changes, but you can’t, because the code base became too legacy to work with.
How to deal with it?
By telling your boss the actual time needed to do the change. No, you can’t do it in a hour, because the only thing you can do in an hour is a quick hack, and you’re a professional programmer, not a quick hacks guy.
You’ll often encounter pressure from your superiors. Remember that the duration you give is not negotiable. If the boss wants the feature to be implemented for tomorrow, tell him that there is no way you can do it. Imagine if your boss tells to Boeing that he needs to travel from Seattle to Hong Kong in twenty minutes. Asking you to implement one-week feature in one hour is similar.
Remember that you are a professional programmer, and your boss probably isn’t. This creates an interesting situation where it might look like your boss has a choice, but in fact, you’re the one who takes the technical choices—which also means that it’s your responsibility to take smart choices which makes your company competitive. It’s easy: what your boss wants is high quality, low price and short schedule, all three at the same time. Since what he wants is not possible, it’s up to you to find the right balance.
Always be aware that your boss may not know things you know, so don’t talk to him in technical terms. If you explain that you can do something in a week, or the same thing in two days but this will increment the technical debt, for most non-technical people it means: “I can do this in a week, or in two days if I make an effort.” They don’t know what technical debt is, so they interpret the part they understood. Your boss doesn’t know what testing is, or why common coding style is important, so don’t bother him with those aspects. He shouldn’t need to chose between 95% targeted code coverage or 40% targeted code coverage: again, this is your responsibility as a lead (or sole) programmer of the company.
In the same way, your boss doesn’t know if a feature should take an hour or a week. I stopped counting the cases where my customers were truly convinced that six man-months project can be done by one person in less than a week, and the cases where they were convinced that a change should take weeks of development, while it simply consisted of changing a value of a constant and recompile.
Negotiate and suggest solutions. If your boss wants shorter schedules, suggest to remove this feature or that one, or make this thing more basic. Or find a creative way to fulfill the needs of the customers while reducing custom development to a minimum. Some problems can even be solved without writing any code at all. Your boss is not expected to know that; likely, he doesn’t even know precisely what programming is about.
7