Maybe I've had it pretty hard but from my personal experience, often what happens is that the reason why I can't write unit tests, documentation, or spend enough time in a code review so that the code is maintainable is because either the project manager or the client is always screaming at the top of his lungs that he needs everything done by yesterday.
If you hire an electrician to wire your house, he doesn't say “This costs $3,500 (or whatever) and another $700 to ground everything properly." He says "That will cost $4,200", because he is a professional, and he is going to do the job correctly, or not at all.
Part of our jobs as professional developers is to understand the potential business impact on a feature and not invest time on documentation or unit tests for code that will probably be dropped next week. That said, and not to be harsh—but if you want to be treated like a professional, act like one, and set expectations for how much a feature costs to deliver, rather than breaking your work down into separate tasks and inviting your supervisor to discard the tasks he doesn't understand.
I was going to reply, but you said exactly what I would have. As an electrical engineer, it's been beaten into me from a very early age that my job is not to get shit done quickly, but get it done right. The client always wants things done double quick, and the project manager always wants to meet his crazy deadlines.
The best thing you can do in this situation, is hold your ground and slow the fuck down. Not because you're a recalcitrant bastard, but because you are the one responsible for quality. Once you learn this, and really internalise it, a lot of things fall into place. Projects are a tug of war over the time / cost / quality triangle. Make sure you're pulling your corner.
Listen to me. This is very, very important. Just do the tests anyway. Don't put them in the same repo, do them through the API, and don't go overboard, but for people that scream about needing things yesterday are obviously poor planners, poor planners change their minds frequently and this requires a test suite to keep up with.
You make tests for your own stuff, but 15 other engineers don't make tests. You have partial test coverage and it just becomes overwhelming because 15 people can write more code lines than you can.
You can't do everyone's job. Trying to write tests for the whole team (in addition to your own work) will just exhaust you. But doing tests on your just own code is still better than no one doing it. Better yet, see if you can use it as a tool to convince others and recruit them to your side.
"Better yet, see if you can use it as a tool to convince others and recruit them to your side."
Been there, tried that. I make it as easy as "run this bat file to test everything" in this specific sub-project. And then I watch them make some silly little "test-program" to debug the thing. Not only that, but we discuss a feature in said sub-project that they're implement and I hear disturbing comments such as "I hope it works" or "I hope it all still works after I'm done".
That's the point where you need to ask yourself if you're doing yourself any favors working on a project with 15 other engineers who don't even write unit tests. Go find a better project and/or company.
The poor planners are in charge. Usually if you're going to build tests, you'll be doing it on your own time. That's where the 60+ hour work weeks come from.
If you're not going to build tests, you'll spend 4x in debug sessions and also get "fear of change".
I worked in a project where we had 80%+ branches coverage in unit tests and awesome automated regression package for end-to-end. When you have that, you have a luxury to be lazy in predictions what would break if I fix this. 90% of defect were business-related, not stability or functionality issues.
It entirely depends on the culture. In my career I've worked in test centric environments, and I've worked in places were testing was nearly forbidden. You can guess which ones generally run smoother. Some places just really care about cranking code out the door, and the people in charge don't realize how badly they're shooting themselves in the feet. It's more common than you'd think.
But I agree with everything you're saying, which is why I try to get into more test centric cultures when job hunting.
Spend the time to do all that stuff anyway. It's part of your job as a developer and they don't need to know the breakdown of how long it took you to finish the work or what you did with every minute of every day.
What's really lovely is when you take the electrician's attitude (professionalism), and always do the tests and documentation anyway, and then find that you are avoided for new jobs because of your "perfectionist" attitude and longer job estimates.
Eventually some of the management may learn how unwise this is, but it can take a long time, especially when many projects don't end up being successful/used by intended users anyway (which is its own drag on morale). I don't work in this environment anymore, thankfully.
I'm ambivalent about this. The idea of professionalism is innately appealing, but in many cases I think programmers are too unwilling to put themselves in the project manager's or customer's shoes and try to understand why they believe they need things yesterday. Most of the time they aren't just meanies, but rather have very real constraints they are attempting to work within, things like "will I even be able to pay all these salaries if this doesn't get to market in the next two weeks?" or "will I have to lay people off because our budget for next year is cut if we don't meet our goals?", which they are insulating people from.
What? No, 99% of the time it's just "if I ask for it faster the guy will work harder"
Maybe it's because I've worked in smaller teams but there was no real pressure to deliver a month earlier. When we presented to other people in the company they don't really care if we covered 38% of cases this month or 42%, they simply don't know what those numbers mean.
I guess your mileage may vary? I have yet to come across people who are pointlessly cruel, but have come across a few who were thought to be, but actually had understandable motivations that very few people bothered to wonder about.
Depends on the culture of the workplace if this will work. If they have many developers, who really underestimate but always end up over the deadline all the time. Then you give an estimate thats double, your gonna look bad even if your dead on. And they're going to try to push that estimate down.
80% of workplaces are like that.
I think its the incentives of billable hours that does this. They want low estimates, so they can win the work at all costs. They have to do it because other companies also underestimate. That or they think pressure motivates developers, but it really results in terrible code.
I personally advocate using accurate estimates, then applying a discount if you have to.
Underestimating is very common with programmers, yeah, because they think they can do it in the given time, but in reality that almost never happens, at least to my experience.
What is an accurate estimate ? It changes all the time when new pitfalls and problems are discovered during the development cycle. So accurate estimate is something that almost all the time more than the original estimate, if you think logically. So better to just multiply by some factor that is realistic.
Three is a nice multiplier too. Just after I posted this I started to think about it, 8 might be too much, but on complex projects with many developers, it's not even so far fetched, there's always things that we cannot see before we start to work on those, a task that takes on our mind 1-2 days might take up to 2 weeks easily if there is some problem that is not solvable right away.
That's the most bullshit line you hear in companies.
Sometimes we can make it happen, and ship code, but then most of the time somebody has to go in and fix it later to actually be extendable and work in other places than the original use-case..
It doesn't make sense in the long run to do this "fix, patch, fix, patch" non-sense .. but still companies need to ship shit to some deadline, so we do it.
This has been my experience and that of my peers the last 15 years or so. The easy is answer is "Tell them no" but the problem lies in the fact that those project managers and clients have all the power.
