There is a tremendous power in thinking about everything as a single kind of thing, because then you don’t have to juggle lots of different ideas about different kinds of things; you can just think about your problem.
In my experience this is also the main benefit of using node.js as your backend. Being able to write your front and backend code in the same language (javascript) removes a switching cost I didn't fully realize existed until I tried node the first time.
In my brag document, I like to do this by making a section for areas that I’ve been focused on (like “security”) and listing all the work I’ve done in that area there. This is especially good if you’re working on something fuzzy like “building a stronger culture of code review” where all the individual actions you do towards that might be relatively small and there isn’t a big shiny ship.
This is such a clever way to create a container that otherwise might not have existed for that work. I wonder if this would be a good way to highlight glue work?
Code doesn’t have feelings, doesn’t develop complexes and certainly doesn’t exhibit the most important trait (the ability to reproduce) of that which carries for your genetic strains.
No, the fact that code can't reproduce is not the most important trait here, it's lack of personhood is and that was already adequately described earlier in the sentence.
Thus, even where bosses expect attrition, the data shows they get substantially more attrition than they wanted. As a result, 29 percent of these companies are now facing substantial recruitment challenges, as the scale of resignations created serious operational and staffing problems. This misalignment between expectation and reality has left many companies struggling to fill the gaps left by departing employees.
Good. Justice would demand more, but this will probably have to do.
This is not a discrete project but an ongoing process and should always be competing for focus in strategic decision making.
Absolutely agreed. One limitation of the Iron Triangle concept is that it often seems to be used to make decisions based on a snapshot in time (i.e. which two are we choosing now), when some choices have longer half-lives than others.
Blogging isn’t just a way to organize your research — it’s a way to do research for a book or essay or story or speech you don’t even know you want to write yet. It’s a way to discover what your future books and essays and stories and speeches will be about.
Blogging as a way to "find your voice?"
Writing for an audience keeps me honest.
Working in public as a way to avoid fooling yourself (a la Feynman).
“The first principle is that you must not fool yourself– and you are the easiest person to fool. So you have to be very careful about that.” -Richard Feynman-
By jumping into unfamiliar areas of code, even if you do not "solve" the bug, you can learn new areas of the code, tricks for getting up to speed quickly, and debugging techniques.
Building a mental model of the codebase, as Jennifer Moore says over at Jennifer++:
The fundamental task of software development is not writing out the syntax that will execute a program. The task is to build a mental model of that complex system, make sense of it, and manage it over time.
Thinking about how you will observe whether things are working correctly or not ahead of time can also have a big impact on the quality of the code you write.
YES. This feel similar to the way that TDD can also improve the code that you write, but with a broader/more comprehensive outlook.
Developers who report fast code-review turnaround times feel 20 percent more innovative compared with developers who report slow turnaround times. Code reviews that are completed quickly allow developers and teams to move to their next idea quickly, setting the stage for coming up with the next great thing.
There's a pretty substantial difference between "feeling innovative" and actually being innovative. This leap feels unsubstantiated.
Our research measures cognitive load as the ease of deploying changes, how easy it is to understand code, and how intuitive it is to work with processes and developer tools.
As Cat Hicks points out, these are examples of friction, not cognitive load.
Tech debt is frequently experienced by developers notonly as a difficult source of friction in their day-to-day technical decision-making, but also as a source of ambiguityabout what types of engineering work their organizations value (Besker et al., 2020; Lee et al., 2023).
Interesting that this is considered a source of ambiguity. In my experience tech debt feels more like an expression of the type of work organizations value, reducing ambiguity by making concrete how little this kind of work is valued.
If a developer experience initiative attempts to provide developers with new and adaptive strategies, but the largercontext then invalidates the behaviors by which a person can execute those strategies, psychological outcomes maybe more negative than not intervening in the first place.
Structural problems don't just go away if you only try to treat the symptoms.
The author's byline is styled like a link but is just text.
For instance, think of using a drill to drive in screws instead of using a screwdriver. The former makes work go faster and smoother.
Maybe this is pedantic, but a drill is not actually the right tool for driving screws, a screw gun is. Drills are powerful tools that can be used for driving screws faster, but IMO not smoother.
https://www.hunker.com/13413968/what-is-the-difference-between-a-drill-a-screw-gun
While helpful at times, these distinctions fail to acknowledge that the quality of the internal tooling and even the technical infrastructure can profoundly impact your customers. The tools you build for your colleagues affect the customer experience and their relationship with your company and its products.
I wish more companies understood this, especially the part about technical infrastructure. Stability is customer-facing!
He says that ultimately, about 50% of participants who were screened to be part of the control group couldn’t be included because of continuing symptoms.
Honestly, this should be the headline. A full 50% of people who volunteered to be in the control were actually still suffering symptoms! Half! Of a self-selected group!
The costs of discouraging learning are borne mostimmediately by individuals.
By design
Give technical teams more time for collaboration and documentation, and makedocumentation “count.” Simply put, documentation and other “mundane” tasks of knowledgesharing were the first sacrifice to time pressure.
This absolutely matches my experience.
Roam Command Palette
cmd + p to bring up the command palette
It was only by building an additional AI-powered safety mechanism that OpenAI would be able to rein in that harm, producing a chatbot suitable for everyday use.
This isn't true. The Stochastic Parrots paper outlines other avenues for reining in the harms of language models like GPT's.
pre-mortems [68]
documentation as part of the planned costs of dataset creation, andonly collect as much data as can be thoroughly documented withinthat budget.
If you can't afford to document the dataset, you should not be creating it.
Their investigation of GPT-2’s training data17also finds 272K documents from unreliable newssites and 63K from banned subreddits
Yikes!
Was all this difficulty worth it? Did Robin and his sister receive a better education at the suburban school? According to him, no. The overcrowded school he went to in Harlem was more academically challenging than the suburban one he was bused to in Seattle.
bell hooks says something similar in (I think) the intro to "Teaching to Transgress"
It’s almost like an identity crisis in a way, where you’re trying to cope and also potentially let it go. And just, well, if this isn't the place for me to do this, I have to come to terms with that as well.
A real danger of "bringing your whole self to work."
Grace Lee Boggs
Emergent Strategy
Deploy engines as separate app instances and have them only communicate over network boundaries. This is something we’re starting to do more.
Before moving to this microservice approach, it's important to consider whether the benefits are worth the extra overhead. Jumping to microservices prematurely is something I've seen happen more than once in my career, and it often leads to a lot of rework.
Solving the gargantuan challenge posed by complex chronic diseases demands seismic shifts in research funding, medical training, and public attitudes.
Not to mention the myopic insurance- and profit-driven "healthcare" industry itself.
only by examining a constellation of metrics in tension can we understand and influence developer productivity
I love this framing! In my experience companies don't generally acknowledge that metrics can be in tension, which usually means they're only tracking a subset of the metrics they ought to be if they want to have a more complete/realistic understanding of the state of things.
Glenn Greenwald
I don't think Glenn Greenwald can really be considered "principled" anymore. https://www.thedailybeast.com/is-glenn-greenwald-the-new-master-of-right-wing-media
National Institute for the Conservation of Cultural Property, Caring for Your Collections. Edited by Arthur W. Schultz. New York: Harry N. Abrams, Inc. 1992
https://www.abebooks.com/first-edition/Caring-Collections-Schultz-Arthur-Edited-Schulz/6786185234/bd
When a product manager trusts that the engineers on the team have the interest of the product at heart, they also trust the engineer’s judgment when adding technical tasks to the backlog and prioritizing them. This enables the balanced mix of feature and technical work that we’re aiming for.
Why is it so common for engineering teams to be mistrusted by other parts of the business?
Part of that is definitely on engineers: chasing the new shiny, over-engineering, etc.
That seems unlikely to account for all of it, though.
Rigor is what happens when something inside us dies
Brutal
we need to be sincerely willing to explicitly name the problems we’re trying to face
You can't fight what you can't name
It’s not so dangerous for us to remember that history and for us to get strength from it.
A particular kind of progress.
human beings are human beings, meaning they work together, and they help each other, and care about each other
I love this beautiful definition of humanity, and that it can be backed up with actual history (as well as social science research).