From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers don't care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently trying to explain that speed-to-market is, in fact, directly related to the technical debt accrued on the project for all but the most static and inconsequential things. We must think and communicate about technical debt precisely the way we do to keep errant PMs from drifting off into the Ice Cream Sea of Candyland where all of the half-thought-through ideas they demand be implemented immediately by cutting all corners have no impact on the next set of half-thought-through ideas they want implemented.
New PMs are like children, they tend to only learn the fire is hot by actually getting burnt.
Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I say.
It happens with jr. devs, too. They want to use a singleton to solve a problem, or they want to forgo using any sort of referential constraints in their schemas.
Of course, the PMs and jr. devs always choose the shortcuts. I help them both pick up the pieces afterwards, but I never work overtime for it. The point is to make it clear that nobody other than themselves is responsible for their own mistakes. They led us into the mess, they can lead us out.
After that, everyone seems to get along a lot better and everyone seems super keen on having discussions about the "right" way to do things and how to fit things into the current state of the project correctly.
|| they can have this feature today and in 6 months we grind to a halt
Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had:
PM: "Yes! Cut all corners and get it done today!"
...6 Months go by...
PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..."
PM:"Today, thanks!"
You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do your job.
So when you're told to cut corners today, then in 6 months you can't make magic happen to grant their every whim, you have to let it blow up. They want to be the leader. They are responsible for the failings of the team.
You have to play chicken with them. Because every time you capitulate, all they know is "I got what I wanted". They don't care how much you complained or how many hours off the clock you worked. And honestly, if you tell them it can't be done overnight, and then you do it overnight, you're a liar and they won't trust your judgement ever again. When you say, "can't do it", you have to not do it. Don't make magic happen.
Or just don't work at such places. I have thankfully been out of that bullshit for three years running now.
That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment.
As you say, don't make magic happen. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible.
I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed.
When you work with other developers, actually work together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.
> That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment.
That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech.
There are of course developers who are capable of identifying a market opportunity, conceptualizing a product to exploit the opportunity, building the actual product and getting it into market successfully.
But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries?
> That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech.
Okay you've got a point, it is fairly arrogant; on the other hand, any sort of automation or small script or product is valuable enough that we don't need to be subservient.
> But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries?
That's what I'm asking, why are talented developers allowing themselves to be subservient? That's why I'm wondering why technical managers all the way up to the CTO level are subservient to other departments when it's the product based on technology that determines the success of the company in the end?
And actually, your idea is optimistic; I wouldn't mind low six figures for 10-12 hours a day ;) maybe that's why we're so subservient, we look at our peers in other industries and they're making much less cash money and it's easy to see that we're lucky to be working in a nice air-conditioned office working with something we're typically passionate about.
> That's what I'm asking, why are talented developers allowing themselves to be subservient?
Answer: trying to get a real product to market successfully requires a lot more than small scripts that automate processes.
It's not that automation and the like doesn't have value, but ask the average developer to get on the phone and sell something, or to have a meaningful conversation with a customer, and you might start to understand why other people in an organization (salespeople, product managers, etc.) have some sway too.
If you simply put a bunch of talented developers in a room, chances are you're not going to end up with a successful business.
This is what I'm talking about with offering the alternatives. You can't hide the distasteful "make the pain go away, but not fix the underlying problem" option. You have to give people enough rope to hang themselves, which is thankfully also the same thing as giving them the opportunity to surprise you with their leadership. When you have a heavy-handed PM over you, you have to give them all the information, force the decision on them. Don't make the decisions for them that option A or option B is best. If they want to lead, they have to take responsibility for this stuff. It's up to you to present the options appropriately. "A) I hide the bug, maybe takes an hour, B) I fix it, probably takes a week". You don't know, you might be surprised, he might tell you "do both, A right now then get right on B." Or he might only be interested in A. Either way, if you don't want responsibility for the failures, you have to abdicate responsibility for the successes.
If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug.
While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".
I'm not going to slag on the developer; the manager got a better short term outcome. The longer than 1 week outcome is that I've had to go back and re-visit that code and make sure it's "done done for reals it's done" due to the lack of unit tests and thorough thought given to it.
On a long enough timeline, the better outcome turns into multiple bugs.
It sounds like you have a bad relationship with your PM. I've been in that situation before (seriously, check my post history), and it poisoned my attitude for quite a while.
There are a lot of terrible PMs out there, but there are also a lot of really good ones, and you learn to suss out which is which when you're interviewing for a new team. If you read Rands in Repose and start wishing your PM actually thought and cared about the things he talks about, maybe you need to find a new job.
From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture.
Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I told you so" stance should things work out not perfectly under an agile model.
I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing.
This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no problem making a reasonable business case for fixing them. If working on it's really causing that much pain, then the developers will figure out a way to quietly fix it in a way that doesn't (and needn't) vex the product owner. If neither of those is the case then you best let sleeping bears lie.
Just because you don't think anything is wrong in terms of external acceptance criteria, does not mean that there is not something wrong with the code that is of real consequence.
Contrarian anecdotes aside, the reason everyone knows the phrase "technical debt" is because SO MANY of us see projects wrecked by greedily demanding many features and changes as fast as possible in a continuous crunch mode, without considering long-term costs like defect rate or turnaround time on bugfix and feature implementations... or developer burnout.
It's better not to assume that developers are blathering when they ask for formal permission to carry out QA or maintenance tasks or upgrades, if they are the people who know what the work looks like on the ground level. If you are putting lots of time pressure on developers and implying that heads will roll if aggressive deadlines are missed, it doesn't make sense also to leave it up to those developers to magically find the time to fix lurking internal time-bombs.
This makes products worse, it makes developers' lives worse and developers are stuck with the blame for something they can't control. Maybe as a PM or whatever that suits you, to dump all the risk in the laps of your developers. But if you are yourself an engineer you should not make yourself part of this problem.
I wouldn't want to make myself a part of that problem. If I found myself on a project where the business folks didn't care about things like defect rate or supportability, I'd be looking for a new job pronto. Those things aren't invisible to the business, they're a core part of the customer's value perception. A product manager who doesn't understand that is a product manager who doesn't have the slightest idea how to manage a product.
Similarly, living in continuous crunch mode is something I let myself get bamboozled into quite a bit in my younger days. I bake time to leave the camp cleaner than I found it into my effort estimates, and I know how not to let myself be pushed past my limits. If I worked for a place that couldn't respect that, I'd also be looking for a new job pronto.
I hope that you were being hyperbolic for rhetorical effect in your post, but if your work environment is really like the situations you were describing then I would also encourage you to be looking for a new job pronto. Life's too short to waste on that kind of stress.
Words of wisdom for sure. I'll add that voting with your feet is a common thing for developers to do, and poor management, being poor at management, won't notice it for what it is.
Eh, referential transparency is a thing. And that idea can be extended beyond a simple function.
It's totally possible to contain horrible sins behind a clean API. I've done horrible things, but those things don't leak all over the whole project.
On the other hand, i worked at the same place for a long time. I got to see the benefits and consequences of my mistakes and successes over years. I do think i burned out. It took me a long time to learn how to contain nuclear waste.
In the end, it's easier to just work someplace that doesn't put crazy demands on developers. There's a continuum of perfection <-> functionality. unfortunately for new developers, it takes a while to figure out where you lie on that line. Finding a place that's close to your preference is really best.
It's kind of like driving. Everyone slower is a Sunday driver, everyone faster is a lunatic with a death wish. I'm happy with homogeneous drivers - too far from the mark and i get nervous. I'd bet it's the same for pretty much everyone else as well.
Had a startup fail because we tried to do the right thing instead of "Fuck it, ship it". Worked at another place where the codebase finally curled up into a ball and refused to accept any refactorings short of a complete rewrite of some core systems--at which point we discovered some nasty bugs in production that we punted to our support folks to deal with. I've no idea if they ever eventually sorted it out.
Good engineers will recognize when it's "good enough". However, that requires biz folks that can provide useful feedback and actually get things in front of customers and get paid. Because, honestly, if we're like three extra features in, have no validation, and are cutting corners, you're damned right I'm going to put on the brakes and redirect the effort toward paying off technical debt.
Because, and this can't be overstated enough, whether or not the business fails in six months is not something we engineers can control--but I'll be damned if I'm going to come in and keep sinking my dwindling life force on a fucking technical lemon. If your biz folks can't establish trust in their abilities, then you might as well hone your craft.
EDIT:
Large amounts of technical debt are a sign of either rapid growth or bad management. If the company is growing, we can overlook the debt every time we, say, waste 30 minutes waiting on a build or fixing a weird nested CSS bug or some other damn fool thing. If the company isn't, then we lose respect for everyone above us in the technical leadership, because they let--by deliberate neglect!--the situation get so bad.
