411–420 of 534 posts
Most of my engagements consisted of replacing politics-driven complications with simple solutions.
The bigger problem was first quietly showing all the affected people other interesting things that needed doing so they would let go.
And TBH, the simple stuff lasted the longest because it harder to misunderstand or misrepresent.
* You can have a bunch of simple code for a latent or implicit concept that is complex; and that making the code more complex might make the reflect principle simpler.
* You have trade-offs: If one aspect is simple, other aspects must become more complex to accommodate.
* There is no consensus over what constitutes complex vs simple code.
Relatedly, I'm periodically thinking about the issue of people who prevent problems not being rewarded as much as those who become "heroes" for resolving avoidable situations I guess it may be important to underscore the value that simplicity provides over needless complexity or to sell people on the value of problems prevented rather than preventable catastrophes that were dealt with Maybe we could encourage a cultu…
The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.
I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)
Earlier quoted context omitted.
> "now what if we wanted to build it in-house?" "Well I would probably go home and work on my resume because that's a fool's errand." I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing stan…
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
Earlier quoted context omitted.
> none of those organizations ever trained me at anything at all They trained us repeatedly not to bribe foreign government officials, even though I had zero access to anybody like that. There was also some mandatory training against harassing coworkers. I.e. "protect the company from lawsuits" training, not "here are some ideas for how to do your job more effectively" training. They were megacorps, too.
> "protect the company from lawsuits Yeah that's proven by the fact they get degree educated level engineers and force feed them videos designed for people working entry level positions. Its a crying shame because there's actually a lot of interesting discussions around nuance that are just sidelined by these videos creating basic bitch absurdities: > During the lunch break, Jim has dipped his penis into Samantha's y…
Wrong. Her yogurt, her culture.
Earlier quoted context omitted.
Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it. If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.
> Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this.
So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change).
Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized.
You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed.
Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions.
Go for the middle path.
Earlier quoted context omitted.
Not sure if you're kidding or not, but to write great maintable code, you need a lot of understanding that a LLM just doesn't have, like history, business context, company culture etc. Also, I doubt that in it's training data it has a lot of good examples of great maintainable code to pull from.
Neither do most humans writing such code, i have seen llms generate better code than 90% of coders I have seen in the last 20 years
Or worse: for not relying as much as possible to the AI who apparently can write just as bad code but faster!
A subtle detail: you speak of coders, not software engineers. A SWE's value is not his code churning speed.
Long rant, but the author never defines what he means by "simple". He heavily hints at smaller changeset == simpler . Too often the smallest changeset is, yes, simple, but totally unaware of the surrounding context, breaks expectations and conventions, causes race conditions, etc. The good bit in tfa is near the end: > when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. Try: “Here’…
For example, if you implement a job framework of things calling a REST API to do stuff async, a sufficient first implementation is a simple monolith doing the stuff and some retries or periodic calls. Because, if it does not scale, we can start thinking about replacing that with something to put things into queues and scaling stuff-doers horizontally and such. But often enough, these simple things scale quite the distance.
On the other hand, if you start introducing in-memory caches into a singular instance to taper around database performance... that's a huge issue. That always leads to pain.
Additionally though, I"ve started to keep notes about people doing simple, efficient things without fanfare. This way, if my boss asks me what Bob did over the year, I can tell them that Bob made these problems disappear and how Bob is starting to handle this area of topics more and more. Suddenly Bob is growing responsible for this area, and if my boss asks Bob about these topics they did well in an annual review, Bob can shine. Hope they learn though.