What makes a good engineer also makes a good engineering organization (2024)

This is the Moxie that created Signal.[0]<p>I&#x27;m pointing this out because people are acting like he&#x27;s a bit naive. But Moxie has built a very successful company, without the need for VCs, and the tech is used by many big tech companies. Several use the signal protocol. It&#x27;s a successful nonprofit building open source software.<p>If your focus is to make large amounts of money, maybe his isn&#x27;t the best advice. But if you&#x27;re trying to make a high quality product, then I think it is good advice. It depends which you prioritize: profits or money. Obviously you can have both, but when push comes to shove, will you sacrifice the product for profits or will you sacrifice profits for the product?<p>Personally, I believe as engineers our focus should be on the product. The profits are the domain of the business people. The contention we have is good, it creates balance. If engineers overly dominate products roll out too slow and only appeal to other engineers. If business people overly dominate we sell broken garbage. Neither situation is great but which side of the spectrum would you like to be on?<p>[0] <a href="https:&#x2F;&#x2F;signal.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;signal.org&#x2F;</a><p>[note] sure I know it&#x27;s popular to hate on Signal but let&#x27;s be real, this is technical nerdy shit we&#x27;re arguing over (see the too much engineering side). Not something that&#x27;s actually broken

&gt; a filmmaker can use a camera to make great films without understanding in detail how to build the camera, and there is probably not much of a predictable relationship between knowledge of how the camera works and quality of the resulting film.<p>This sentence conflates two different things to support a single point. One is true but the second is not. It&#x27;s correct that a filmmaker does not need to know &quot;how to build a camera&quot; to make great films. However, a filmmaker certainly needs to know &quot;how a camera works&quot; to make a great film. And not just in the pedantic sense of where the Record button is but in the sense of a great violinist needing to know how their violin works (but not how to make a violin). The camera is the artistic instrument of cinema and using it well requires understanding how to leverage lens selection, aperture, shutter speed, exposure, focal plane, lighting, framing, etc to achieve the desired artistic outcome.<p>Another possible confusion in this sentence is the catch-all term &quot;filmmaker&quot; when the actual example is more narrowly focused on operation of the camera. Deciding how to apply a camera toward making a motion picture is generally the responsibility of the cinematographer. Sometimes uniquely skilled directors can also act as their own cinematographer but the roles and skill sets are as divergent as composer and violinist.

Great read. One thing that stood out..<p>&gt; As we’ve made it easier to build games, we have certainly seen more of them. But the number of highly rated games (in this case as recorded by metacritic) does not seem to be increasing over time.<p>There are unspoken constraints at play: size of the gamer audience, percent of gamers who rate and review games (ie. journalists &amp; reviewers), number of developers willing to make something &quot;insanely great&quot;, and even the total number of game concepts that actually exist.<p>When asking why systems develop the way they do, we can look at all possible constraints. This means ones that do and don&#x27;t exist. For example - organizations are structured and siloed the way they are because it keeps complexity within the constraints of what humans can deal with. Or on the other hand, organization headcount grows at successful firms because money is growing on trees; and it unlocks speculative parallel product development. The latter was especially true during ZIRP.<p>A good engineer understands the constraints of engineering and how that interplays with achieving a vision. But orgs can do far more, which is why a majority of shipping products come from orgs and not individuals. Orgs can achieve greater range of capabilities - shipping multiple products at once for example..<p>Yes: orgs <i>should</i> be better geared to feed engineering knowledge into devisions of what&#x27;s achievable &#x2F; what to do. There should be more cross-talk, just as among the many compartments of a human mind.<p>But there&#x27;s a rich discussion to be had of how different constraints mean individuals and orgs excel at different things.

The first half is this essay asserts that software engineering is like a science because &quot;software development is actually full of discovery&quot; and not the &quot;engineering practice of combining and assembling what is available from the complex system of computing in order to manifest a given vision.&quot;<p>This is extremely poor understanding. All engineering is full of discovery. Electrical engineers are constantly discovering new circuits that do the same task but with different resource usages and performance trade-offs. Civil engineers are doing the same thing with buildings. etc.<p>&gt; Software development has the benefit of relying on abstraction layers....<p>So does every other engineering discipline. You think every new machine is built from first principles?<p>&gt; Computing is so complex that these interfaces are never perfectly clean...<p>Author seems to imply that this is something unique to computing. Probably because they have never tried to build a complex analog circuit by assembling together a bunch of component circuits.

&gt; The people who create software generally refer to themselves as software engineers<p>Engineers follow processes and measure things. If a developer is not measuring things, most are not, then they are not engineering. If, at least, they are doing something new they are writing. Otherwise, they are typing. Software employs a lot of typists.<p>If you want to select for excellent engineers you only need to identify two qualities: conscientiousness and persistence. Conscientiousness is awareness of the world outside yourself and is negatively correlated with intelligence. Conscientiousness is where you find disciplined industriousness. Add a little bit of intelligence and you also get people that can follow complex instructions and achieve high precision. Creativity is the child of persistence and high intelligence. Creativity is achieved by trying many variations of a process and carefully discerning quality against some audience or metric.<p>If you hire a bunch of clowns you get a circus.

Totally agree that the best stuff happens when vision and engineering evolve together. Some of the most creative breakthroughs I&#x27;ve seen didn’t come from someone executing a top-down plan, they came from someone who deeply understood the system and just noticed a better way.

&gt;the real opportunity lies in understanding that you’re not bound by the conventions that have been passed down as “standard.”<p>While in agreement with the author, I think Moxie is missing here that if you want external funding you are in fact mostly bound by conventions, conventions that most VCs and investors expect you to follow. It&#x27;s possible to go beyond the normal funding routes as well but it narrows the path considerably.<p>Perhaps though, VCs will change their mindset about this as the AI-driven company becomes vogue and strengthens the perception of small orgs doing big things.

It&#x27;s a bit annoying to see something I think is worth keeping on a website, only to find that the author has excluded their website from the Wayback Machine. Now the content can&#x27;t be stored easily in a reliable way. I would have to host it myself and make some solution to find it.

It would be great to put Carmack and Moxie in a room to discuss low level software.

It&#x27;s a good point about confirmation and survivorship biases. However, the Skype example is really an example of what happens when your codebase has coupling where there shouldn&#x27;t be. Encapsulation is a foundational concept in software engineering for a reason. That doesn&#x27;t mean that it&#x27;s not useful to know, e.g. the inner workings of your database. But it&#x27;s unreasonable to expect that anyone at your software company can know more than a surface amount about what other teams do.

The two landscape GIFs, or I guess color cycles on this page are absolutely beatuiful, wow. Don&#x27;t remember the last time I was stuck looking at animations, just because they&#x27;re so satisfying to look at. Not even sure why they seem so special to me...<p><a href="https:&#x2F;&#x2F;moxie.org&#x2F;blog&#x2F;images&#x2F;falls-colorcycling.gif" rel="nofollow">https:&#x2F;&#x2F;moxie.org&#x2F;blog&#x2F;images&#x2F;falls-colorcycling.gif</a><p><a href="https:&#x2F;&#x2F;moxie.org&#x2F;blog&#x2F;images&#x2F;ocean.gif" rel="nofollow">https:&#x2F;&#x2F;moxie.org&#x2F;blog&#x2F;images&#x2F;ocean.gif</a>

The point about how increasing the number of Steam games published didn&#x27;t increase the number of critically acclaimed Steam games, and therefore, volume decreases average quality, is very weird. It&#x27;s the wrong conclusion to draw when an alternative, like the volume of reviews didn&#x27;t increase along with the number of games published, exists.

Thanks for sharing! I had never really thought about the difference in meaning between the words Science and Engineering in this context.<p>I’ve had discussions with coworkers before about how we should describe ourselves, but never quite in terms of actual job titles. I really like the black box analogy you mentioned. It reminded me of something I came across recently — Conway’s Law.

Engineering often supplies the potential energy fueling vision and vice versa. ARPANET was very specifically engineered with the vision of a network that could survive nuclear attack. Then it evolved into the internet, which fueled a new vision of collaboration and discovery for students, hackers, and researchers. Who in turn created systems that became new business models, and the cycle goes on.

The author writes:<p>&gt; Just like with software, where deep understanding is often the basis for discovery, an organization has to truly understand itself to be primed for innovation. When teams operate as impenetrable black boxes, vision becomes myopic, and potential withers. Despite having immense talent, the large engineering organizations of SV often structure themselves in ways that isolate expertise. As a result, they’re probably sitting on a huge amount of untapped potential – creative and technical ideas that never connect.<p>Then continues:<p>&gt; If you’re building a company or an engineering team today, I think the real opportunity lies in understanding that you’re not bound by the conventions that have been passed down as “standard.”<p>It feels like there would be very few people who would have bota (a) a deep understanding of the different ways that software devs can be organized and (b) the conviction to “compose” a radically different organization based on that understanding. (Bryan Cantrill is popping into my head for some reason as someone who might fit this mold.)

This seems to be the key paragraph:<p>&gt; Clearly things need to change. Almost everything needs to change. But the change that every team needs to make is dependent on the change that every other team needs to make. The product vision itself is intertwined and bidirectionally informed from the engineering, but if everyone in the organization sees every other part of the organization as a black-box abstraction layer, I don’t think a change like that is going to happen.<p>Basically: In order to create a really outstanding product, every member of an organisation needs to have some insight into what every other member of the organisation does.

Weird, maybe it&#x27;s because I&#x27;m mostly gray haired at this point, but I find myself referring to my profession as &quot;Computer Science&quot; more and more as time passes.

The chart of games vs highly rated games, as evidence of more stuff, but not more good stuff, is thought provoking.<p>It also seems possible that, at least to some extent, the overall quality of games has gone up with the volume, so people have become more critical. I don&#x27;t play enough games to know. What&#x27;s the gamer consensus?

&gt; As we’ve made it easier to build games, we have certainly seen more of them. But the number of highly rated games (in this case as recorded by metacritic) does not seem to be increasing over time.<p>In some ways, ratings given out by reviewers, and even their sentiments, is a zero-sum game since most things are rated compared to other things in the same stretch of time.

If you take film maker comparison with game engine from TFA. i would say there is no difference here. As cameras got more and more accessible (paralell to game engine) more and more people started recording videos (making games). This does not mean that we have corresponding increase in oscars distributed. We just got youtube filled with millions of videos like we have steam filled with lots of indie game developers.

&gt; I think there is something uniquely magical about software, and part of that magic might stem from this tension in how we define it.<p>Well, yes, but I&#x27;d phrase this differently. To me, there is something uniquely <i>unprofessional</i> about software, and part of this <i>unprofessionalism</i> stems from our <i>lack of understanding</i>.<p>If you do get a computer science degree, congratulations! You have more knowledge than 90% of the people I&#x27;ve worked with in my 20-year career. But even then you only have the &quot;book knowledge&quot;; you still lack the real-world knowledge that comes from practicing a profession. Tradespeople are required to have both the book knowledge, and the practical knowledge (from working under a master). This solves a lot of problems by filling in the gaps that books leave out or haven&#x27;t updated to yet.<p>Software feels like magic because there&#x27;s so much to know. Even for experts, knowing &quot;how to do something right&quot; isn&#x27;t totally clear. I think the cause of the uncertainty is software engineering&#x27;s lack of standardization.<p>Not long ago, the world had no standard units for making buildings. Nails, bolts, wooden beams, sizes of walls, framing layout, roof design, etc varied widely. Making a building strong enough not to fall over, be blown over, shaken apart, or burn down in 10 minutes, required over-building it, because you didn&#x27;t actually know how to figure out if it would fall over or not. But now the component parts of a building are made to a set minimum standard. Building codes lay out exactly how you can construct a building so that it&#x27;s safe to use. It&#x27;s still not <i>easy</i> to construct a building, but at least we know exactly how to do it, and we can check that it was done correctly. In this way, an expert <i>can</i> know exactly how to build a building the right way. Because of this, construction isn&#x27;t magic. In fact, it&#x27;s often derided as a job for people who aren&#x27;t smart, yet you have to be fairly skilled to do any part of it well!<p>Software engineering still lacks the certainty that physical engineering figured out long ago. Apparently software isn&#x27;t important enough for people to need to quantify it yet. As is usual with humans, it takes a busload of kids getting creamed by someone speeding through an intersection for us to finally put stop signs in place. I expect after the next world war, when our society is brought to its knees by a simple computer virus, security will become standardized and required, with liability for the &quot;engineers&quot; who don&#x27;t follow the protocol.<p>....none of this has to do with organizations, though. Nothing magic about organizing software engineers. Successful management strategies that work at other companies, also work in software companies. There are additional management strategies that can help the lowest level of work become more efficient (<a href="https:&#x2F;&#x2F;www.atlassian.com&#x2F;agile" rel="nofollow">https:&#x2F;&#x2F;www.atlassian.com&#x2F;agile</a>), but those things require the boring, old, &quot;normal&quot; management to be done correctly first. This has been written about to death by people who&#x27;ve studied it all their lives. But software people stick to their software people blogs, and software people management strategies, and never branch out to see how the wider world works. Then they wonder why it all seems like magic.