> If the business insists that customers are complaining, they just show the charts as if that explains anything. Charts don’t absolve you. They just mean you’ve given up without learning much at all.
This mirrors my own experience in the industry.
When clients complain that loading some data in a CRUD app takes them upwards of 6 seconds in a bespoke ERP system, they're met by the blank stares of some devs. A cursory review of the code reveals that what could have been a single SQL query is instead a bunch of service calls which ends up being a textbook example of the N+1 problem. And when asked about this, the devs respond with: "But it's easier to use service calls to get the data because of code reuse, working with complex SQL queries is harder."
Well, you picking the easier way out caused the performance to be bad in this case, especially because of your needless queries lead to degraded performance for all of the users in the app.
But how could you even get to that point? Because the other devs who did the code review were struggling to even review the overcomplicated business logic in the new code. Because they didn't care enough to ask about the architecture and the N+1 problem, or because they simply didn't see it in the overcomplicated codebase. Because the merge/pull request description is literally blank because no one cares about keeping track of ADRs (architecture design records) or even the historical context for certain changes. Because there has been very little care put into load testing in any capacity so far, because the system doesn't lend itself nicely to testing or even setting up new environments, any attempt to do which is met with resistance from ops. New features get mostly prioritized over maintenance, addressing technical debt or solving these longstanding issues, both from the client company and management side. And when things inevitably do break, the devs are blamed for seemingly not doing this all on their own time.
That disconnect between what should be done if anyone actually cared about software engineering and what is actually done in the industry irks me greatly. I hate the short term thinking that makes systems perform badly in the long term and hard to maintain. That is not sustainable in any way whatsoever.
Luckily, i've basically just said "no" to the above and for the past N months have been working on modernizing the app, adding proper APM instrumentation and monitoring, improving environment setup whenever possible (enterprise DB is still an issue, everything else currently being managed with Ansible) and introducing containers for easier runtime management and health checks with restarts/load balancing, while also writing unit tests (some of my new code has 100% coverage, actually) and addressing technical debt.
At this point, i don't care if it earns me scorn, pressure or if i get fired because of it down the road - i'm an engineer (with a degree that says exactly that) and that's what i'll do, asking neither permission, nor forgiveness (while clearly communicating what i'm doing as a matter of fact). Sure, there are times when you have to cut corners and ship things or help others with sub-optimal solutions, but i wish that more people in the industry didn't waiver under pressure from management and didn't choose to lie about estimates just to please them.
I have asked, romanced, and forced better process on different teams over the years and the fact is that some people just have never had anything better than chaos or bureaucracy and so they don’t know the level of accidental pain they’re carrying around until they get a taste of something better.
In a couple instances a former coworker told me after I left that the boss tried to walk back some of my changes and was surprised that the majority said no. Our theory is they thought I was being mean, rather than tough love.
I keep joking with my beer group that I am going to hire a personal trainer just to have them talk me through how they get people to do things that are good for them but painful in the short term. There is some fundamentally different thought processes between people who have never been “in shape” and those who aren’t now. I know my “reasons” are excuses and I know what the carrot tastes like. For some that carrot is too abstract and sounds maybe a little culty.
> There is some fundamentally different thought processes between people who have never been “in shape” and those who aren’t now. I know my “reasons” are excuses and I know what the carrot tastes like. For some that carrot is too abstract and sounds maybe a little culty.
Sure, part of it could be due to the experiences that shape people's opinions. For example, i've stood in a governmental building and have seen queues forming because people could not receive the healthcare services that they needed in a timely fashion, all due to a system not working. I was called in to help and admittedly there was a lot of satisfaction/relief after i pulled out the non-functioning guts of the system and replaced them with something a bit more stable.
I think that developers could benefit from seeing how their code runs out in the wild, or even dogfooding their own projects. Furthermore, actually getting to be a part of a good team that's not constantly fighting some fires is definitely an eye opening experience!
Similarly, that one situation made me reconsider how much impact my decisions could have down the road for both others and myself. Do i really want to skip out on writing unit tests now and then spend a week fixing both some rather bad bug whilst also trying to fix the data that has been damaged by it? Should i really approve these code changes, if it seems like the implementation could cause resource usage issues, even without doing a few benchmarks first? Is saving 15 minutes by not writing docs worth wasting 2 hours rediscovering all of the functionality when something will break 4 months later and i'll have no recollection of this code?
Of course, i'm not infalliable myself, far from it. Thus the balance between "strong opinions that are loosely held" vs "loose opinions that are strongly held" is hard to find and i have to constantly keep exposing myself to new technologies and approaches, even if i don't always agree with them. Ideally, i also have to make a large amount of mistakes, but in environments where their consequences are minimized, such as side projects and prototypes, so that i may learn from them.
Here's hoping that i won't lose the strength and discipline to continue doing that for the following decades, and leave all of the software that i work on in a better state than it was when i started.
This mirrors my own experience in the industry.
When clients complain that loading some data in a CRUD app takes them upwards of 6 seconds in a bespoke ERP system, they're met by the blank stares of some devs. A cursory review of the code reveals that what could have been a single SQL query is instead a bunch of service calls which ends up being a textbook example of the N+1 problem. And when asked about this, the devs respond with: "But it's easier to use service calls to get the data because of code reuse, working with complex SQL queries is harder."
Well, you picking the easier way out caused the performance to be bad in this case, especially because of your needless queries lead to degraded performance for all of the users in the app.
But how could you even get to that point? Because the other devs who did the code review were struggling to even review the overcomplicated business logic in the new code. Because they didn't care enough to ask about the architecture and the N+1 problem, or because they simply didn't see it in the overcomplicated codebase. Because the merge/pull request description is literally blank because no one cares about keeping track of ADRs (architecture design records) or even the historical context for certain changes. Because there has been very little care put into load testing in any capacity so far, because the system doesn't lend itself nicely to testing or even setting up new environments, any attempt to do which is met with resistance from ops. New features get mostly prioritized over maintenance, addressing technical debt or solving these longstanding issues, both from the client company and management side. And when things inevitably do break, the devs are blamed for seemingly not doing this all on their own time.
That disconnect between what should be done if anyone actually cared about software engineering and what is actually done in the industry irks me greatly. I hate the short term thinking that makes systems perform badly in the long term and hard to maintain. That is not sustainable in any way whatsoever.
Luckily, i've basically just said "no" to the above and for the past N months have been working on modernizing the app, adding proper APM instrumentation and monitoring, improving environment setup whenever possible (enterprise DB is still an issue, everything else currently being managed with Ansible) and introducing containers for easier runtime management and health checks with restarts/load balancing, while also writing unit tests (some of my new code has 100% coverage, actually) and addressing technical debt.
At this point, i don't care if it earns me scorn, pressure or if i get fired because of it down the road - i'm an engineer (with a degree that says exactly that) and that's what i'll do, asking neither permission, nor forgiveness (while clearly communicating what i'm doing as a matter of fact). Sure, there are times when you have to cut corners and ship things or help others with sub-optimal solutions, but i wish that more people in the industry didn't waiver under pressure from management and didn't choose to lie about estimates just to please them.