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...

  • 5
    It could be bad. It could be not so bad. It could be catastrophic. It depends on the opinions of your co-workers (you are doing code reviews... right? right?), the actual conventions you are breaking, and if you are introducing security vulnerabilities in the code or not. Talk to your co-workers about the code and have them look it over.
    – user40980
    Oct 11, 2014 at 4:34
  • 1
  • 3
    Code reviews are not just for seniors checking your code, but also to get another set of eyeballs on it and to aide in knowledge transfer and bus number mitigation.
    – user40980
    Oct 11, 2014 at 5:14
  • 1
    As to fighting schedule pressure - How to be a programmer: How to fight schedule pressure. You may wish to get a copy of Software Estimation: Demystifying the Black Art which has material on how to estimate, and also how to communicate estimates to management.
    – user40980
    Oct 11, 2014 at 19:13
  • 1
    The stack overflow mods who voted this as opinion based are hurting StackOverflow. Oct 13, 2014 at 17:18

1 Answer 1


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.

  • I'm not a web programmer but I suppose also the time estimation could be a problem. Might be easy to choose between 0.30 h and one week but not so easy for other estimates
    – Marco A.
    Oct 11, 2014 at 8:06
  • 2
    One of my favorite tactics is: Never tell the "no," but always inform them of the consequences. Oct 11, 2014 at 15:11
  • 5
    @GregBurghardt: according to my experience, this doesn't work with some people. You inform them, they agree and ask to do it fast without consideration of quality, and then when something goes wrong, you are the culprit, since they already forgotten all the discussions you had with them six months ago (and the details of the agreement they signed). Oct 11, 2014 at 16:03
  • 5
    @HelpNeeder: there is an important point which I didn't include my answer: since, according to you, you are "the only person there that really know how to code", use it at your benefit. Your boss doesn't ask you to do dirty hacks, because he probably doesn't know what a dirty hack is. What he asks is to implement a feature quickly enough. The actual implementation, would it be a dirty hack or a clean, elegant piece of code with clever architecture, is up to you. Oct 11, 2014 at 18:11
  • 1
    @MainMa: I've had the same thing happen. Follow up all in person meetings with a summary e-mail. When they make a stupid decision and try to pin it on you pull out the e-mail where you warn them about the problem that just happened. You only have to do this once or twice with people. You can turn the Titanic, but not before it hits the iceberg. Oct 12, 2014 at 12:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.