And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction.
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
100% agree. Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Simple:
1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.
2. People lost any tangible connection to the quality and quantity of their output.
Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.
To quote Office Space: “That makes a man work just hard enough not to get fired.”
3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.
They are exploited for gain and dumped when no longer needed.
What happened is that most companies do not care about their employees, and their employees know it.
If anything happens, the company will lay off people without a care for what happens to them.
Even when they do care, such as in a smaller company, their own paycheck is being weighed against the employees, and they will almost always pick themselves, even if they caused the problems.
CEOs making millions while they lay off massive amounts of people is the norm now, and everyone knows it.
You can't blame the employee for not caring. They didn't start it.
>I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Because there's still people doing less work than you do for a bigger paycheck
Because you'd get fired or laid off for someone working for 1/2 to 1/4th of your pay
Because they make you jump through multiple rounds of interviews and technical tests while people above you have a far less barrier to being hired
Because someone stole credit for your work
Because you'd get re-hired and find a mountain of shit code from a company that off shored their dev team
Because companies stopped giving significant raises that didn't keep up with major inflation in the past few years, while your work might have gotten them many multiples more of profits
People have to be interested in their jobs to care about it. Corporations know that people rarely get to do whatever they want, so they assume (correctly) that most workers do not care, so they move on to care about processes, workflows, which makes even less workers care about their jobs.
For individual workers, the best thing is to work @ something you love && get good pay. Like a compiler engineer, a kernel engineer, an AI engineer, etc.
What is wrong with just wanting to work for money?
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Many employers actively discourage people from doing work that they are proud of. You cannot be proud of something that is built as cheaply as possible.
You can get employees to care about customers or the product, you cannot get employees to care about profits and dividends.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Anecdotal, but I used to be proud of the work I produced, and then it got old and repetitive. However, as it was getting old, I was earning more. Now I'm in a place where if I were to quit and find something I could be proud of, I would have to accept a huge reduction in compensation. No thanks.
I'd rather have a much higher "just a paycheck" and find things to be proud of outside of work. Plus no one else cares anymore so why should I? Just pay me a lot and I'll keep showing up.
> Or you have a leader above who has no idea and goes with the quickest/cheapest option.
This leader is not going with the quickest or cheapest option. Doing so would probably be laudable. They are going with the claims made by someone that a certain way is going to be quicker or cheaper. It doesn't matter if it actually is, or ends up being, quicker or cheaper. One plan is classified as meeting the requirements while another plan is classified as being cheaper, the cheaper one will be chosen even though it doesn't meet the requirements.
> I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down…
To the great surprise of my younger self I have never seen “it all come crashing down” and I honestly believe this is extremely rare in practice (i.e. the U.K post saga), something that senior devs like to imagine will happen but probably won’t, and is used to scare management and junior devs into doing “something” which may or may not make things better.
Almost universally I’ve seen the software slowly improved via a stream of urgent bug fixes with a sprinkle of targeted rewrites. The ease of these bug fixes and targeted rewrites essentially depends on whether there is a solid software design underneath: Poor designs tend to be unfixable and have complex layers of patches to make the system work well enough most of the time; good designs tend to require less maintenance overall. Both produce working software, just with different “pain” levels.
I'd really wish there was a better way to allocate compatible people together.. the distribution is often subpar.. lazies with motivated people drowning to fill in. If you change the ratio and let creative / driven / team-spirited work together you get exponentially better results.
Frankly, something that I don't see discussed enough is the truth that many people are plain stupid. If my position in the company depends on stupid people, then this completely changes the game, because then good engineering isn't the best way to maximize my status anymore. That's how you get smart people spend their time coming up with elaborate tactics to appear productive while in reality they aren't and play office politics. All successful corporations understand this and build processes around the assumption that their workers are idiots, which has the side effect of suffocating smart workers, but the truth is, ten thousand morons is a bigger force than a hundred geniuses.
Work is just a paycheck because I am just a number for my employer. Why would I be proud of my work when apparently according to management I should be replaced by AI at some point because im just a cost factor.
Why would I care about the business at that point? Fuck the higher ups, I'll be proud of my work and actually put in effort if I can afford a house.
> for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Hard to be proud of the work you produce when you have no ownership over it, and companies show less and less loyalty and investment in their employees. When, at any random time, you can be subject to the next round of layoffs no matter how much value you contributed, it's hard to care.
So yeah, for most it's just a paycheck unless you are working for yourself, or drank a gallon of the koolaid and seriously believe in whatever the company's mission is/what it's doing.
I'm proud of my own work and projects I do for myself, tech or otherwise, and put great care into it. At $dayjob I do exactly what I am paid to do, nothing more nothing less, to conserve my own mental energy for my own time. Not saying I output poor work, but more so I will just do exactly what's expected of me. The company isn't going to get anything extra without paying for it.
Didn't used to be that way, but I've been burned far too many times by going "above and beyond" for someone else.
If employees had more ownership and stake in the companies they work for, I think the attitudes would change. Likewise, if companies went back to investing in training and retention, loyalty could go both ways again.
> Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck.
I found that most of the "people problems disguised as technical problems" are actually generated by people who get far too invested in their work and let it define them. They get territorial, treat any lost argument as an attack on their whole self, etc. They also lose perspective, getting into flame wars over indentation styles or minor API syntax quibbles.
People who show up for the paycheck are usually far more reasonable in that regard.
> I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect
I recall there was a whistleblower Richard Roll who said that engineering did know of the bugs and flaws
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Millions of boocampers and juniors trying to make a quick buck; any tech work that is not “make it, and make it quick” is punished; tech debt swept under the rug; any initiative is being shut down because status quo is more important; “we’ll optimize when it becomes a problem” on 15 seconds page reload; dozen of layers of parasites and grifters making your life hell, because their paycheck depends on it; salary bumps that don’t even cover inflation – the only way to actually move in life is to join, raise as much hell as possible in 2 years and jump ship leaving the fallout for the next SOB in the line.
And that’s just what I bothered enough to type on bad iOS keyboard.
Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues.
"But what about using a message queue.."
"Candidate did not use microservices.."
"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
In my most recent role, everyone interviewing me gave me a thumbs up. Except one engineer.
I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.
Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).
Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
I've found presenting arguments from both sides, i.e. presenting the tradeoff, to be effective in interviews. Especially because if the team I'm considering doesn't recognize the tradeoffs, then I can avoid joining up with them.
As a data engineer in big tech, the two hardest problems I deal with are:
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
Jerry Weinberg, Secrets of Consulting (1985) - "No matter how it looks at first, it's always a people problem." - no matter how technical a problem seems, its root cause always involves people—their choices, communication, management, or skills—making human factors central to any solution, from software development to complex systems
Jerry Weinberg wrote a number of books to this point, starting with 1971's 'The Psychology of Computer Programming.' Here's what he had to say a decade or so later...
"The First Law of Consulting: In spite of what your client may tell you, there’s always a problem.
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0]
Everything he wrote is worth the time to read.
[0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
I worked as an analyst on a team doing a system replacement.
The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate.
The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case.
Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system.
After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded.
I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem.
We were overruled and forced to implement the technical solution to the human problem.
At this point I'm fairly senior and work directly with funding sponsors and requirements owners. The gal who 100% owns the problem, worldwide, says "I need X, how much it going to cost?", while X is a big, hairy ball of wax and I have 18 minutes left in the 30 minute meeting to get as many details as I can while I work up a guesstimate. Because the funding line will be decided by minute 30.
They have no idea what's going on technically. But they know where the money is and the words that have to be spoken to certain people to get and defend that money. I have been handed a problem that was estimated to cost $6M and solved it with a text message, in the meeting. Shoulda taken the money. I have also had a project poached from me, watched the new team burn $35M and come out the other end with nothing but bruised egos.
The sponsors with the budget are definitely folks who prioritize politics over everything else. They have generally have bachelor's or master's degrees, rarely doctorates. You look at their career and wonder how they got there. Their goal is not mission success. Their goal is the next job. They've been dressing for the next job their whole career. The financial folks are afraid of them, or at least very wary.
This is why I hate it when people are judged (like the article writer is doing) for doing what their job requires of them and not “taking pride in their work” - the thing is, the workers generally don’t own the work, the business does. If the business wants something a certain way, and if they act to punish you for trying to push back, why fight them? It’s not our company. We’re cogs in a machine, if they treat us like that then what do they expect?
This article has a stink of self importance that rubs me the wrong way.
> I had one developer openly tell me, "I don't want to learn anything new."
To play Devil's Advocate here, there's a big, big difference between JavaScript-ecosystem-style framework/library/fad-of-the-month where you are nagged on a daily basis that your libraries and tools are out of date, to building everything in Go on the back of the standard library, deploying to some LTS distribution.
The benefits of technical stability for product agility are real. Yes, it may mean your codebase is in a subset of C++ and is the domain of a 50+-year-old, genuinely-Senior Engineer who's been writing C++ for more than thirty years, who you will need to sit and negotiate with to make product changes. C'est la vie. Calling that tech debt, in and of itself from the outside, is not really fair, that's ageist.
There are precisely two people who can determine whether or not there is technical debt: (a) the lead IC responsible for the codebase, according to their innate understanding of the state of the codebase, (b) the manager who is responsible for the IC who both (1) observes that release agility is at risk and (2) is willing to invest in non-functional work to get future increases to release agility.
Technical problems are generated by lack of knowledge. One type of lack of knowledge is interaction with people. You'll never know everything that another person wants to communicate to you because of several reasons.
But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.
The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
I think I'm mostly of the opinion these days that there is no such thing as an "outdated technology". There are technologies that are no longer fit for purpose but that is almost never because of their age. It nearly always because of one of as examples: Needing to run in an environment it can't support, Having bugs that are not getting fixed/no longer maintained, Missing features necessary to solve new problems or add new features, Hitting scale limits.
Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
I'd also add "there are almost no developers using it on the job market" to the list why some technologies are no longer fit for purpose. It's a major one.
Sort of tied to the ecosystem (no devs - not many things get mantained/created).
> Most Technical Problems Are Really People Problems
The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
Well technical debt is not really a technical problem, it’s a choice.
Someone at some point said: ok we’re going to duplicate code, we’ll have a windows version and a Linux version, and yes it’ll be painful - for a while - but at this stage, it is the better option.
At some point getting shit done might be more important than getting it right.
Whether that is smart or not is a people problem.
Working on large legacy codebase is extremely annoying indeed, but sooner or later, in everyone’s career one has to make those sort of tradeoffs, and when that day comes maybe you’ll forgive those who came before you.
Edit: I want to add this:
Also those tradeoffs are often required because of business problems. It’s difficult to see, 10 years down the road, how shitty the business may have been when those decisions were made. And perhaps, it’s some of those business-driven decisions - like rushing the product out the door no matter what - that kept the company afloat and made it so that you have a job (albeit to fix the mess) today.
The author suggested that if senior leadership had a development background then tech debt would be easier to get support and resources to deal with. Between the lines I'm reading that the risks are just inherently understood by someone with a tech background.
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
Isn't this generally the case across all sectors and industries? We have the technology today to create a post scarcity utopia, to reverse climate change, to restore the biosphere. The fact that none of that happens is a people problem, a political problem, a spiritual problem, more so than any technological barrier.
> Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable.
I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business.
Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
You need to make people include some sort of objective evidence with their argument, and either have a (hopefully benevolent) dictator solve the "vim vs. emacs" problems or just let people pick their environment and sort out any issues they create themselves.
If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
Ha. At my last job, I observed that we were so good at solving technical problems that we transformed social problems into hard technical problems so we could solve the original song cial problem. It's something like a problem reduction in Algorithmic Complexity Theory. There was perhaps a simpler social-centric solution, but we didn't have a method for solving those...
[+] [-] jeffheard|3 months ago|reply
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
[+] [-] woodylondon|3 months ago|reply
I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
[+] [-] Hendrikto|3 months ago|reply
Simple:
1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.
2. People lost any tangible connection to the quality and quantity of their output.
Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.
To quote Office Space: “That makes a man work just hard enough not to get fired.”
3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.
They are exploited for gain and dumped when no longer needed.
[+] [-] wccrawford|3 months ago|reply
If anything happens, the company will lay off people without a care for what happens to them.
Even when they do care, such as in a smaller company, their own paycheck is being weighed against the employees, and they will almost always pick themselves, even if they caused the problems.
CEOs making millions while they lay off massive amounts of people is the norm now, and everyone knows it.
You can't blame the employee for not caring. They didn't start it.
[+] [-] hnthrow0287345|3 months ago|reply
Because there's still people doing less work than you do for a bigger paycheck
Because you'd get fired or laid off for someone working for 1/2 to 1/4th of your pay
Because they make you jump through multiple rounds of interviews and technical tests while people above you have a far less barrier to being hired
Because someone stole credit for your work
Because you'd get re-hired and find a mountain of shit code from a company that off shored their dev team
Because companies stopped giving significant raises that didn't keep up with major inflation in the past few years, while your work might have gotten them many multiples more of profits
Idk it's just a mystery we'll never know
[+] [-] nkrisc|3 months ago|reply
My local grocery stores won’t accept pride as payment for food, and working harder doesn’t make my paycheck increase.
[+] [-] ferguess_k|3 months ago|reply
For individual workers, the best thing is to work @ something you love && get good pay. Like a compiler engineer, a kernel engineer, an AI engineer, etc.
[+] [-] Noaidi|3 months ago|reply
What is wrong with just wanting to work for money?
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
[+] [-] graemep|3 months ago|reply
Many employers actively discourage people from doing work that they are proud of. You cannot be proud of something that is built as cheaply as possible.
You can get employees to care about customers or the product, you cannot get employees to care about profits and dividends.
[+] [-] stronglikedan|3 months ago|reply
Anecdotal, but I used to be proud of the work I produced, and then it got old and repetitive. However, as it was getting old, I was earning more. Now I'm in a place where if I were to quit and find something I could be proud of, I would have to accept a huge reduction in compensation. No thanks.
I'd rather have a much higher "just a paycheck" and find things to be proud of outside of work. Plus no one else cares anymore so why should I? Just pay me a lot and I'll keep showing up.
[+] [-] thwarted|3 months ago|reply
This leader is not going with the quickest or cheapest option. Doing so would probably be laudable. They are going with the claims made by someone that a certain way is going to be quicker or cheaper. It doesn't matter if it actually is, or ends up being, quicker or cheaper. One plan is classified as meeting the requirements while another plan is classified as being cheaper, the cheaper one will be chosen even though it doesn't meet the requirements.
[+] [-] jt2190|3 months ago|reply
To the great surprise of my younger self I have never seen “it all come crashing down” and I honestly believe this is extremely rare in practice (i.e. the U.K post saga), something that senior devs like to imagine will happen but probably won’t, and is used to scare management and junior devs into doing “something” which may or may not make things better.
Almost universally I’ve seen the software slowly improved via a stream of urgent bug fixes with a sprinkle of targeted rewrites. The ease of these bug fixes and targeted rewrites essentially depends on whether there is a solid software design underneath: Poor designs tend to be unfixable and have complex layers of patches to make the system work well enough most of the time; good designs tend to require less maintenance overall. Both produce working software, just with different “pain” levels.
[+] [-] agumonkey|3 months ago|reply
[+] [-] anal_reactor|3 months ago|reply
[+] [-] zwnow|3 months ago|reply
[+] [-] thewebguyd|3 months ago|reply
Hard to be proud of the work you produce when you have no ownership over it, and companies show less and less loyalty and investment in their employees. When, at any random time, you can be subject to the next round of layoffs no matter how much value you contributed, it's hard to care.
So yeah, for most it's just a paycheck unless you are working for yourself, or drank a gallon of the koolaid and seriously believe in whatever the company's mission is/what it's doing.
I'm proud of my own work and projects I do for myself, tech or otherwise, and put great care into it. At $dayjob I do exactly what I am paid to do, nothing more nothing less, to conserve my own mental energy for my own time. Not saying I output poor work, but more so I will just do exactly what's expected of me. The company isn't going to get anything extra without paying for it.
Didn't used to be that way, but I've been burned far too many times by going "above and beyond" for someone else.
If employees had more ownership and stake in the companies they work for, I think the attitudes would change. Likewise, if companies went back to investing in training and retention, loyalty could go both ways again.
[+] [-] chemotaxis|3 months ago|reply
I found that most of the "people problems disguised as technical problems" are actually generated by people who get far too invested in their work and let it define them. They get territorial, treat any lost argument as an attack on their whole self, etc. They also lose perspective, getting into flame wars over indentation styles or minor API syntax quibbles.
People who show up for the paycheck are usually far more reasonable in that regard.
[+] [-] willvarfar|3 months ago|reply
I recall there was a whistleblower Richard Roll who said that engineering did know of the bugs and flaws
[+] [-] dvrj101|3 months ago|reply
ignorance against wrongdoers has been a bliss for your generation, curse for ours and deadly for future
[+] [-] merrvk|3 months ago|reply
[+] [-] wiseowise|3 months ago|reply
Millions of boocampers and juniors trying to make a quick buck; any tech work that is not “make it, and make it quick” is punished; tech debt swept under the rug; any initiative is being shut down because status quo is more important; “we’ll optimize when it becomes a problem” on 15 seconds page reload; dozen of layers of parasites and grifters making your life hell, because their paycheck depends on it; salary bumps that don’t even cover inflation – the only way to actually move in life is to join, raise as much hell as possible in 2 years and jump ship leaving the fallout for the next SOB in the line.
And that’s just what I bothered enough to type on bad iOS keyboard.
[+] [-] stardude900|3 months ago|reply
[+] [-] another_twist|3 months ago|reply
"But what about using a message queue.."
"Candidate did not use microservices.."
"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
[+] [-] iterance|3 months ago|reply
[+] [-] btreecat|3 months ago|reply
I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.
Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).
Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
[+] [-] unknown|3 months ago|reply
[deleted]
[+] [-] morshu9001|3 months ago|reply
[+] [-] liampulles|3 months ago|reply
[+] [-] munchbunny|3 months ago|reply
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
[+] [-] philk10|3 months ago|reply
[+] [-] mooreds|3 months ago|reply
[+] [-] pjmorris|3 months ago|reply
"The First Law of Consulting: In spite of what your client may tell you, there’s always a problem.
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0]
Everything he wrote is worth the time to read.
[0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
[+] [-] veryfancy|3 months ago|reply
[+] [-] FatherOfCurses|3 months ago|reply
The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate.
The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case.
Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system.
After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded.
I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem.
We were overruled and forced to implement the technical solution to the human problem.
[+] [-] 0xWTF|3 months ago|reply
They have no idea what's going on technically. But they know where the money is and the words that have to be spoken to certain people to get and defend that money. I have been handed a problem that was estimated to cost $6M and solved it with a text message, in the meeting. Shoulda taken the money. I have also had a project poached from me, watched the new team burn $35M and come out the other end with nothing but bruised egos.
The sponsors with the budget are definitely folks who prioritize politics over everything else. They have generally have bachelor's or master's degrees, rarely doctorates. You look at their career and wonder how they got there. Their goal is not mission success. Their goal is the next job. They've been dressing for the next job their whole career. The financial folks are afraid of them, or at least very wary.
[+] [-] ChrisMarshallNY|3 months ago|reply
That describes so many projects that I've seen, over the years.
One of my first programming projects, was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975.
No comments, no subroutines, short, inscrutable, variables, stepped on by dozens of junior programmers, and the big breadwinner for the company.
Joy.
It was probably the single biggest motivation for my uptight coding style, since. I never want to do to others, what was done to me[0].
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
[+] [-] jama211|3 months ago|reply
This article has a stink of self importance that rubs me the wrong way.
[+] [-] solatic|3 months ago|reply
To play Devil's Advocate here, there's a big, big difference between JavaScript-ecosystem-style framework/library/fad-of-the-month where you are nagged on a daily basis that your libraries and tools are out of date, to building everything in Go on the back of the standard library, deploying to some LTS distribution.
The benefits of technical stability for product agility are real. Yes, it may mean your codebase is in a subset of C++ and is the domain of a 50+-year-old, genuinely-Senior Engineer who's been writing C++ for more than thirty years, who you will need to sit and negotiate with to make product changes. C'est la vie. Calling that tech debt, in and of itself from the outside, is not really fair, that's ageist.
There are precisely two people who can determine whether or not there is technical debt: (a) the lead IC responsible for the codebase, according to their innate understanding of the state of the codebase, (b) the manager who is responsible for the IC who both (1) observes that release agility is at risk and (2) is willing to invest in non-functional work to get future increases to release agility.
[+] [-] etamponi|3 months ago|reply
But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.
The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
[+] [-] intrasight|3 months ago|reply
Or a lack of action. Tech breaks and you need to take the action of preparing for that.
[+] [-] zaphar|3 months ago|reply
Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
[+] [-] amonith|3 months ago|reply
[+] [-] anonu|3 months ago|reply
The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
[+] [-] d--b|3 months ago|reply
Someone at some point said: ok we’re going to duplicate code, we’ll have a windows version and a Linux version, and yes it’ll be painful - for a while - but at this stage, it is the better option.
At some point getting shit done might be more important than getting it right.
Whether that is smart or not is a people problem.
Working on large legacy codebase is extremely annoying indeed, but sooner or later, in everyone’s career one has to make those sort of tradeoffs, and when that day comes maybe you’ll forgive those who came before you.
Edit: I want to add this:
Also those tradeoffs are often required because of business problems. It’s difficult to see, 10 years down the road, how shitty the business may have been when those decisions were made. And perhaps, it’s some of those business-driven decisions - like rushing the product out the door no matter what - that kept the company afloat and made it so that you have a job (albeit to fix the mess) today.
[+] [-] deelayman|3 months ago|reply
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
[+] [-] N_Lens|3 months ago|reply
[+] [-] quadrifoliate|3 months ago|reply
I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business.
Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
[+] [-] bpt3|3 months ago|reply
If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
[+] [-] kmoser|3 months ago|reply
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
[+] [-] xorvoid|3 months ago|reply