Tagged: work-culture

Timber Stinson-Schroff:

If I have a regret, or a cautionary tale, it might be reading Thinking In Systems: A Primer by Donella Meadows. Meadows was apparently a wonderful woman, and she wrote a solid book. But if you’re a twenty-one year old desk jockey, like I was, systems thinking is basically a hard drug. Books like Meadows’, or The Fifth Discipline by Peter Senge, to name another example, will juice you up with a dangerous amount of hubris and delusion about your agency. Why? Well, it’s one thing to know where to look for leverage points in a system (places where you can make a lot of change without a lot of effort, basically). But there are some complicating factors…

This is an interesting take — that Systems Thinking is not good for young analysts, not because the ideas are wrong, but because it makes the said analysts misjudge their abilities and influence. I haven’t seen much commentary that doesn’t deride an idea but warns a certain group of people of its dangers.

Sean Goedecke:

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do.

I'm becoming a fan of this Sean Goedecke. Such good writing. No fluff at all. Read the entire post—it's well argued.

Sean Goedecke:

There are two very different kinds of programming work. The first kind - pure engineering - is interested in solving a technical problem as perfectly as possible. Open-source work is often like this: some engineer wants to write the best HTTP requests library, or their ideal game engine. The second kind - impure engineering - is interested in solving a real-world problem as efficiently as possible. Paid tech company work is often like this: engineers are asked to deliver some project or feature as well as they can do it by the deadline.

In pure software engineering, what you’re doing is close to art or research. It’s close to art because the engineer is driven by an aesthetic sense (e.g. of what makes a good library or game engine). It’s close to research because it’s open-ended: once the engineer arrives at a solution, they can continue testing and tinkering forever, trying (and usually discarding) new approaches.

Impure software engineering is more like plumbing or construction. The engineer’s aesthetic sense is subordinated to someone else’s (usually their employer’s) needs. They’re building a solution to someone else’s problem. And since it’s someone else’s problem, it has to actually be finished to schedule, which means compromising.

Dan Moore:

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

The example in the post demonstrates this well. Me likes.

David Oks:

Kyocera was founded in 1959 as a producer of ceramic insulators for cathode-ray tubes; today it manufactures not only industrial ceramics but also printers, smartphones, ballpoint pens, kitchen knives, solar PV modules, lens components, industrial cutting tools, automotive camera modules, electronics components, semiconductor packaging, biocompatible tooth and joint replacements, UV-LED curing systems, LCD systems, medical products, and lab-grown gemstones. Or another e-chuck maker. Sumitomo Osaka Cement, as you might have been able to deduce from the name, produces cement and ready-mixed concrete; but it also produces optical components, measuring instruments, industrial ceramics, artificial marine reefs, cosmetics and nanoparticle materials.

Long fascinating read.

Benedict Evans:

Many people would like to analyse which jobs, companies and industries are most exposed to AI, and assign scores, build charts, and map that against the progress of LLMs. I think this is mostly impossible: you don’t know how the jobs will change, you don’t know what else will change around this, and you can’t measure work like that anyway.

Lots of commentary out there on the impact of AI on jobs, mostly on the lines of “AI will lead to massive job losses” (tch. Dario).

This is a more nuanced take from Evans. It may feel a little unsatisfactory given the crux of the argument is that nobody can predict where this will go (a common theme of much of Evans’ writing), but I strongly believe it’s a very good framework for thinking about this.

Recommended reading. Don’t just take the conclusion, nod, and move on. Developing a deep appreciation for why you should disregard most predictions about AI is important to actually do the said disregarding.

Arnav Gupta:

But the truth is that these layoffs, even if they they are not because AI is replacing you, and even if they are some form of AI-washing. These layoffs are still because of AI. And these layoffs will continue till we learn to use AI. Till we learn to convert AI-tokens into outcomes and not just input. Till we learn to re-align the speed of "alignment" with the new speed of coding. And till we figure out, beyond our 2 good and 8 stupid ideas, 10 more ideas that we can chase with our increased productivity.

This is a very refreshing take on the layoffs in large tech companies. It’s the best take I’ve read on this.

Denis Stetskov:

Five to ten years from now, we’ll need senior engineers. People who understand systems end to end, who can debug distributed failures at 2 AM, who carry institutional knowledge that exists nowhere in the codebase. Those engineers don’t exist yet because we’re not creating them. The juniors who should be learning right now are either not being hired or developing what a DoD-funded workforce study calls “AI-mediated competence.” They can prompt an AI. They can’t tell you what the AI got wrong.

Ignore the click-baity title. This is a well-written and well-argued post on how the software industry might be hurtling towards a grim future, the kind of present that the West’s defence industry has found itself in as an unexpected war broke out between Ukraine & Russia.

Mo Bitar:

What we do is because the deal is so damn good, we change ourselves to make that deal acceptable.

And what I've figured out now is that I'm unwilling to change myself to make that deal acceptable.

I could feel the emotions as I watched the video. Well worth the time.