What makes a good engineer also makes a good engineering organization (2024)
moxie.org
moxie.org
I'm pointing this out because people are acting like he'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's a successful nonprofit building open source software.
If your focus is to make large amounts of money, maybe his isn't the best advice. But if you'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?
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?
[note] sure I know it's popular to hate on Signal but let's be real, this is technical nerdy shit we're arguing over (see the too much engineering side). Not something that's actually broken
Related issues:
https://github.com/signalapp/Signal-Android/issues/13704 https://github.com/signalapp/Signal-Android/issues/12341 https://github.com/signalapp/Signal-Android/issues/10336 https://github.com/signalapp/Signal-Android/issues/9729
- They claim full open source but for several years they did not release the server.
- They claim federation is impossible… yet matrix has it.
- They claim openness but are actively hostile to linux distributions and f-droid.
- Related, getting signal from an app store is no more secure than getting any random proprietary app.
- There's a lot of allegations that they don't need VCs because they have backing from the USA army.
> Signal facing collapse after CIA cuts funding
> https://english.almayadeen.net/articles/analysis/signal-faci...
However, widely disseminating an app that supports secure e2e messaging can serve a positive purpose for the CIA in running its agents.
Association with the CIA or In-Q-Tel is not necessarily a bad thing. They have unique requirements for operational security like many other Signal users?
The CIA has access to zero-days. They will just use those for targeted attacks and are generally not in the business of mass surveillance? Whereas the FBI and NSA sorta are to achieve their respective mandates
The State department has since walked back its love for international freedom of speech with the populist movement in Brazil. They’re active in suppressing speech there, just like they were in promoting it in the Middle East.
> funding for Tor came from the Navy
Similarly, CIA/Navy/whatever doesn't want their tools to have zero-days. You might think "zero-days for me, but not for thee" but come on... we all know that doesn't work. If there's an exploit, the exploit works for anyone. You may have an edge in knowing where to look, but you're not going to maintain that edge for long. Worse, good luck finding out if someone else finds out. How do you prevent adversaries from exploiting your tools? Doesn't take a genius to figure that out...
I really hate these conspiracies. Like come on. Yeah, we should be highly critical of US spy agencies and apply a lot of scrutiny. But not everything they touch results in a landmine. They aren't all powerful gods. And they're up against some serious adversaries like China, Russia, and yes, Israel, and the most important one of them all... themselves! Spooks are spooks. They don't trust their neighbors, they don't trust themselves.
And if they were omniscient, surely they'd know the very first rule of security: if there's a backdoor, somebody will find it at the least conveniently possible time.
The Washington Post:
In a statement, WikiLeaks indicated that the initial stockpile it put online was part of a broader collection of nearly 9,000 files that would be posted over time describing code developed in secret by the CIA to steal data from a range of targets. WikiLeaks said it redacted lists of CIA surveillance targets, though it said they included targets and machines in Latin America, Europe and the United States.
and:
The experience of O.S.B. engineers bore some resemblance to the Apple TV+ drama “Severance,”
I mean the critiques are mostly valid but wanted to point out they're mostly technical.
I really wish the server was fully open. I feel like that could actually create a mixed federated ecosystem. At worst be optional, right? I can get where he's coming from (and now Meredith), but I think there's a lot of value in it and they've solved hard problems before. Even just the ideas of mesh nets in local areas could be a real win for privacy and security.
Being a Linux user and signal user for quite some time I'm confused at that critique. What's hostile? That it's electron? I mean that does suck but I've used various open source desktop versions and some TUIs. No real issues so far. What am I missing?
Generally the talk I hear about government money is implications of back doors. Just seems like they are more interested in getting encrypted communications into other people in other countries hands. At least that's my understanding of the mission of the organization that's funding them. They'd want that as secure as possible. Government isn't a single entity. If the complaint is morally taking money from the government, yeah it was a weird move. Kinda seems out of character. But not too crazy. Personally I'm okay if they aren't building weapons and there's no strings attached. My understanding is it's not enough money to justify that.
Like selling you no chemical fertilisers vegetables and then using them anyway.
It's hostile because they want you to use their binary build… which you don't know if it corresponds to the source they have online. And can't verify due to the binary blob.
edit: you trust the USA army to not ask any control in exchange for that money? Remember there's no reproducible builds really, and that installing via app store which is linked to an account is very easy to send vulnerable versions to journalists or whistleblowers.
Look, I'm mostly with you. My point is that the issues we argue over are only things us nerds care about. Not the average person.
> you trust the USA army to not ask any control in exchange for that money?
From what I know, the money was not through the military. It was through Radio Free Asia, an organization suspected to have ties to the CIA. Notably, the CIA is concerned with foreign targets, not at home. So like I argued, it is entirely reasonable for "the government" to want perfectly encrypted communication systems in the hands of people they want overthrowing a current regime while also not wanting that service to be used at home.
The government isn't a single super intelligent entity working together. It is a fucking shit show of organizations (and sub-organizations) with entirely opposing goals.
They're a non-profit... their books are open. If you are really concerned, switch to Molly. Or idk, use iMessage, WhatsApp, or Telegram. Because those have far less suspicion, right? Sure, you could use Matrix, but I can't get my grandma to use Matrix, but I can Signal. I'll take what I can get.
> but I can't get my grandma to use Matrix, but I can Signal
Why not? On the phone they look just like any other messaging app.
I don't know how you can cherry pick the technical detail and and ignore what that means without making me suspect you're being dishonest.
Just in case you are honest. It means that you cannot verify the application, so it's no more secure than any proprietary application.
And signal is marketing themselves as MOST SECURE THING EVER!!!!! People should be aware that their main marketing point is false.
Yet take zero action against TeleMessage.
Citation needed. Strange allegations (and from whom?) when the pentagon itself has discouraged using Signal in an official capacity...[0]
[0]https://abcnews.go.com/Business/what-is-signal-messaging-enc...:
> The Pentagon's internal watchdog criticized a former official's use of the Signal app in 2021, calling it a breach of the department's "records retention policies" and an unauthorized means of communicating sensitive information.
> "Signal is not approved by the DoD as an authorized electronic messaging and voice-calling application," the report asserted, adding that "the use of Signal to discuss official DoD information does not comply with Freedom of Information Act requirements and DoD's records retention policies."
I believe the claim was that it's hard to adapt to changing markets and be federated [1]. Comparing Signal's market share to Matrix's is obviously not a direct cause-and-effect, but Matrix hasn't yet proven that you can get mass adoption that way.
> - They claim openness but are actively hostile to linux distributions and f-droid.
I'm too lazy to find the specific GitHub comment, but IIRC there was a specific list of features they'd need to actively support F-Droid. It is now available in the Guardian Project's F-Droid repository though [2].
[1] https://signal.org/blog/the-ecosystem-is-moving/
[2] https://guardianproject.info/apps/org.thoughtcrime.securesms...
Neither has signal. I can contact more people with GPG than with signal.
At the same time, it has reached far more regular users than Matrix has. I believe market penetration is at about 15% here in the Netherlands, which is a ways off from WhatsApp, but a pipe dream for Matrix.
Specifically, they didn't publish the source for their server-side from 20 April 2020 to 6 April 2021 [0] while they secretly added a cryptocurrency payment system to which Moxie was a paid technical advisor [1], which Moxie denied they were doing in January 2021 [2].
0: https://www.androidpolice.com/2021/04/06/it-looks-like-signa... (source was published shortly after the publication of that article)
1: https://news.ycombinator.com/item?id=26715013 (comment from founder of MobileCoin)
2: https://www.theverge.com/22249391/signal-app-abuse-messaging...
They absolutely do NOT claim that, at least from a technical point of view:
https://signal.org/blog/the-ecosystem-is-moving/
> Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.
For example: Signal doesn't need a cryptocurrency implementation. Signal does need a commercial product offering so they're not just donation funded (there's several obvious, useful applications here - they're doing none of them).
None of the builds are actually verifiable so all of the security claims are marketing at best and actively harmful at worst. Safety numbers change and nobody ever bothers to verify them. Random people are added by phone number with no verification (signalgate), etc.
Making a messaging app like this is the “make a TODO” of the single user app world. Which ones achieve popularity has zero correlation with engineering skills.
Regardless, those instructions are useless for iPhone: https://community.signalusers.org/t/add-reproducible-builds-...
You need business skills to run a non-profit as much as you need to run a "for-profit" business or any organization really. Your goal may not to be "to make a profit", but cost control is essential to any organization.
Really, it's a balance of priorities.If you focus too much on the $$$, you risk destroying the business and doing a disservice to your customers. You also have a responsibility to your employees who depend on your business for their livelihood, and so forth.
Certainly some engineers have to float in the middle too. Bridging engineering and business. Vise versa too! But there is good value in splitting focus between groups (even if those two groups are in the same person). One hat focusing on the product, ensuring that you make the thing that the customer needs, to provide value to the customer. The other hat to focus on making the company not just operational, but as profitable as possible. Together you need to make the company operational. Combined: the engineer constrains the manager to make as profitable while providing maximal value to the customer; the MBA constrains the engineer to not get too lost in technical problems and make profits so that more time can be spent doing those things.
I am not arguing for "no business people". That would be a silly argument. Nor am I arguing this need to be a complete dichotomy. Most people will fall somewhere on some spectrum and realistically that location will change over the course of their career. Traditionally that is moving more towards business but hey... the only reason that happens is because we (or rather business people) decide it is that way. There's no reason it has to be.
I hope you understand I'd never make the argument that you'd go so far as kill the business because the product isn't perfect. Certainly it can be too bad but that's a different case all together.
This is the dumbest idea in tech. Please don’t listen to this advice. If you’re just starting your career I’m begging you not to laser focus on coding widgets better for the sake of it.
Care about your customers and what problem they are trying to solve and be involved in figuring out how to make solving those problems a profitable endeavour.
All code is throwaway, all code is worthless, solving real needs, wants and pain points for customers is the real source of value.
If someday it produces messy but actually reliable code my opinion will change, but at this point, it's just too early (not saying it will ever work, but one can hope)
Caring about the customer is caring about the product. Caring solely about profit is what enshitifies products.
Certainly you have non-techncal managers that are making more money than you and do you think they do more work? Certainly some do but I doubt all.
How is that focusing on the product?
Focusing on the product means solving problems for your customers, exactly what you said they should be doing
You're both arguing for the same thing
I was hoping that dichotomy of sacrificing product for profit or profit for product would help but I'm unsure. Multiple people seemed to have misunderstood but I'm also unsure what was confusing. Frankly I'm having a hard time understanding how they reached such a dramatically different interpretation.
It could be, but it cost my company a billion dollars over almost 10 years (not exact numbers, but close enough) to rewrite our current product from scratch. If you work on trivial projects you can throw away code at will. However for a lot of projects the cost to rewrite is so high that the business cannot afford to throw away code that works. The business needs new features so they can sell upgrades and make more money. The whole reason they were willing to pay that billion dollars over a decade is the old codebase was bad enough that adding new features became expensive and hard - the rewrite was an investment to make adding more features cheaper in the long run.
Which is why engineering a good product is important. People who make the product technically good pay for themselves in the long run when the business gets an idea. This is very important to business as well.
The engineer’s job is to care deeply about the technical aspects of doing well by the customer.
> Care about your customers and what problem they are trying to solve and be involved in figuring out how to make solving those problems a profitable endeavour.
What I mean by "the product" is making sure it is solving what customers need. And to be clear, by "customer" I mean the people that actually buy it, not share holders.
> All code is throwaway, all code is worthless, solving real needs, wants and pain points for customers is the real source of value.
And again, I fully agree we should focus on needs, wants, and pain points. What I'm trying to argue is if you'll forgo that for making profits. Clearly this is what big tech companies are doing. They're shoving in things that are half baked, people don't want, and solve no problems. But they do it because it increases share prices. I'm saying, don't do that
The original SV was focused on technical advancement and the current generation sees the technology as the vehicle to their goals.
This sentence conflates two different things to support a single point. One is true but the second is not. It's correct that a filmmaker does not need to know "how to build a camera" to make great films. However, a filmmaker certainly needs to know "how a camera works" 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.
Another possible confusion in this sentence is the catch-all term "filmmaker" 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.
The idea that a film artist doesn’t need to know how a camera works is laughable. And not just the camera, but different film stock, processing methods, lenses, lighting, and the interaction of all those as well as the subject being shot. The level of attention to detail in great films is wild.
"I need to figure out what brand of paints and brushes this painter used so I can paint like this."
Of course not! It's the painter that determines the quality of the painting and not the maker of the tools. A great painter (or filmmaker or cook or software engineer or ...) will understand the unique attributes of the tools available and leverage those to do great work, whether that's in oil or water, black & white or color, Python or Rust. A difference between experts and non-experts is that experts will find opportunity in the constraints of the tools they have available, and not only frustration.
I believe this extends to engineering managers. I want managers who are good at spotting the unique advantages of each person on the team and are good at structuring the roadmap and individual projects to let the team get the most out of those advantages. And I want them to spot where advantages and disadvantages can be paired to enable learning. All this helps teams see how valuable their teammates can be and how much they can learn from each other. I've seen it result in teams achieving remarkable outcomes while having a ton of fun doing it.
Scaling this up further... I want senior management that is in tune with the unique advantages of different parts of the org, and who then use that knowledge to make better decisions about direction. We can go in direction A, B, or C... that group over there is great at A, so let's pick that and give it to that group. Some see Conway's Law as a sort of "doom", but I've seen it used to the org's advantage with this kind of thinking.
This is something I'm pushing towards in our overall platform - I'm kind of trying to identify both related things, as well as things of similar necessary velocity or lack of velocity and try to put these into a team or into teams close together. If a team has a large mismatch of velocity between their topics, it tends to be straining, tbh.
For example, frontend teams or teams largely fronting AI features with little persistence to manage want to and need to be fast. These guys want to be able to throw stuff at a wall and see what it sticks, or they want to react to shifting trends very quickly. All good and well. It's valid practice in the right situation.
On the other hand, we're a team handling databases, long term archiving, hardware acquisition and management. Handling these correctly is a direct plug keeping customers lawyers down. Yet,sometimes lead time of hardware purchases, racking, configuration, qualification and full utilization can be a quarter of a year. Note that this doesn't apply to standard requests like restores, database provisioning and such. We can stand up necessary standard persistences for new applications within hours if necessary, or a day or two usually.
In the past, we had these different velocities mixed up in teams and it was a mess and frustration for everyone. We were in the middle of larger storage migrations that require some care, and suddenly there's a sales-project crashing in with an ASAP tag preempting everything else. Or a frontend dev suddenly had to do capacity planning for a CI cluster. Overall silly.
Now the projects requiring planning, capacity estimations, budgets and honestly, old-school project planning are in our court and the dev-teams can rely on that and run free and wild however they want. It's much more effective for both sides.
The Aliens documentary is really good for this. So much of the special effects on the film are in camera tricks.
Cameron is a really interesting person to study because he absolutely mastered every part of film making before deciding to go all in on Avatar and ubiquitous 3d effects.
All of life is “energy conversion”. All of programming is “translation”. All programming is “solving problems”. Etc.
Not all abstractions generalize (in an useful way).
Pianos (like grand ones, but also recent electronic ones with sophisticated key action mechanisms) are built to provide two-way feedback.
There’s feedback on key press. There’s bass rumble you can feel as your feet touches the pedal. This combined with string action can help with building „relation” with the instrument and take from it.
But I still couldn’t build one..
> 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.
This is the key sentence. If you had a digital camera that perfectly mimicked output of film camera, you could take a "filmmaker" from 70s, give them the digital camera and they will successfully create a film of equal quality. Yes, one needs to understand that e.g. focal length changes depth of focus, but it's all about controlling the output. One does not really need to understand the inner workings of a system, all they need to understand is which parameters affect output in what way.
>> there is probably not much of a predictable relationship between knowledge of how the camera works and quality of the resulting film.
Yes, usually some technical understanding is required to understand the relationships and use them well. However, even perfect understanding of inner workings of a tool does not translate to being a good craftsman. There is some overlap, but that's it. One still needs to understand the filmmaking part well to make a good film. Hence, the observation that technical knowledge does not translate to film quality - it's a required, but not sufficient criterion.
You must first prove it's at all possible.
And they could of course not do any of the special effects obtained by compositing images on the same film. And they would have no idea how to do that with a computer.
It's not the same at all.
Yes. That was the point I was trying to make and after reading the responses, I see I didn't make it as clearly as I could have. I think the confusion is in the multiple ways to interpret this phrase in the original article, "knowledge of how the camera works." I thought the examples I cited (lighting, lens, aperture, etc) would make clear how I took that phrase but they didn't do so sufficiently.
I'll give an example. In the example I'll substitute violin for camera again because I think it helps to remove some of the technical nuance specific to cameras. I took "knowledge of how the violin works" to include "knowledge of how to..." apply finger pressure on the strings, rock the strings to create vibrato, use bow strikes, apply rosin - all to achieve. I did not take "knowledge of how the violin works" to mean things like: the effect of internal geometry on acoustic resonance. To me, those are "knowledge of how to build the violin" which I already said wasn't necessary to be great violinist (although the example of 'geometry -> acoustic resonance' is more 'designing a violin', I group design as part of 'building'.
I know see several people took the phrase differently when that interpretation wasn't the point I was trying to make. As a filmmaker, "knowledge of how the camera works" means knowing how to apply lighting, lens, aperture, shutter speed, etc to achieve the desired artistic result. I didn't mean "knowledge of how the camera works" in the sense of "the impact of pre-charge voltages on charge coupled devices", which to me is akin to "the effect of internal geometry on acoustic resonance" in a violin. As I said that's designing a camera/violin, which is part of "knowing how to build it" not "knowing how it works". "How it works" is simply too open to interpretation.
This paragraph tells me you don't understand how cameras work, because what you said is not true. The study of photography, and from it cinematography, is FUNDAMENTALLY about understanding the relationship between light, color, and the camera. This dates back to the beginnings of photography, and is the /primary/ topic written about by many of the world's best photographers (and famously a key area of focus for Ansel Adams). Photography, and from it cinematography, is almost entirely about lighting and exposure, and it requires a deep technical understanding of the inner workings of the camera to do it at a professional level. A cinematographer working on feature length films is not an amateur recording video clips, every element of the frame affects the mood and context of the story that is being told, and controlling for light and exposure is essential and goes beyond merely adjusting settings on the camera until it looks good in the viewfinder, it requires adjusting the actual environment you are recording (e.g. artificial lighting, light control, shadowing) in conjunction with technical details of the camera system, the lens choice, and things like adjusting aperture.
To have no understanding of the basic principles of light and its relationship to the camera, which is the core principle of a camera's operation, makes it impossible to produce professional quality work.
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.
> Software development has the benefit of relying on abstraction layers....
So does every other engineering discipline. You think every new machine is built from first principles?
> Computing is so complex that these interfaces are never perfectly clean...
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.
Like there's like nothing on people management in orgs. Like treating engineers like robots as though they'll unquestioningly follow what the author prescribed.
Civil engineers mostly plan ahead and try to follow that plan, and having to adapt to too many unforeseen issues is a sign of failure (which is not surprising, since planning is a small fraction of the cost).
In software engineering, the opposite is true: large big-design-upfront projects are usually a trainwreck.
In my experience, it is pretty hard to explain the difference to civil engineers that evolved into leadership.
Anything before that is drawings on napkins.
There are no other engineering areas with a similar ratio. And yet, SWE planning and design does look like planning and design on any other area.
The unique part of computing is that complexity can grow way higher and faster than complexity in physical based engineering because it does not suffer from physical limitations and all the NN relations between pieces of shared code and data grow out of hand quick.
Creating something complex in physical realm is hard, and it essentially means doing more work to make something complex rather than simple. The common challenges are rather often about fitting the achieved complexity either in a small physical space (like an engine bay) or building it all out into large installments that look complex (like a nuclear plant). Yet many things in physical based engineering aren't inherently* hard but it will be hard to make it all into something that both fits in a practical enclosure and actually works reliably in practice.
But creating something complex in the realm of compute is rather the default offering. If you just put things together into a program then, in the classic rookie intern fashion, very soon you have something that mostly actually works but is implicitly so intertwined that nobody can understand the resulting interactions and can no longer start depicking the mahjongg of corner cases. Senior-level software engineering could actually be said to be primarily about managing complexity and whatever remains left after that effort can be used to build products and develop the trade. The reason we love abstractions is that they reduce complexity and make things manageable at all. There would be no progress in software engineering without abstractions.
If you were building an analog circuit that is, complexity-wise, on par with writing software systems you'd basically have to write software to design the circuit in somewhat manageable way. That's how software itself is written.
How can you read this article and your takeaway is that "the author is arguing that engineering does not have abstraction or discovery"? How can you read this insightful article and think "this is extremely poor understanding" because the author does not discuss how "all engineering is full of discovery" when that is not even relevant to the topic of the article? Clearly their point is that engineering does have discovery, and they give examples specifically from the domain of software engineering.
If you think that discovery in all fields of engineering is an interesting topic, go ahead and write your own article about that topic. Show examples from plumbing, electrical engineering, and material science. It would be fascinating, it really would be! But that is not this article, nor is it at odds with what the author of this article is saying.
It's difficult to write an article like this. It takes time and consideration, organization and work. Nit-picking generalization which are not core to the argument of the article, on the other hand, is easy. Anyone can do it.
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.
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.
If you hire a bunch of clowns you get a circus.
We have many strong typists.
I don’t think there’s a formula for creativity. Sometimes it happens, sometimes it doesn’t.
Now in a typical house the floor and roof use trusses that are engineered because in those areas engineering matters. Even then they are mostly taking a bunch of trusses already designed and putting their stamp on the system working.
As buildings get larger/more complex though it becomes harder and harder to build the needed charts. Eventually you need a civil engineer to do a lot of calculation (with the help of a computer) because the building is different enough from anything before.
I've not thought much about the relationship between vision and engineering but it does make sense of why early-stage, engineering-led companies have such a potent potential to disrupt industries.
I wonder if the environment is ripening for a new wave of start-up disruption. A handful of folk with vision and know-how actually do have the means to innovate in ways that confound the incumbents.
The momentum of a technology sector converging on the same patterns and practices starts to look incredibly vulnerable to faster moving teams of visionary engineers finding the missed opportunities.
Creative destruction is such a beautiful thing.
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's possible to go beyond the normal funding routes as well but it narrows the path considerably.
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.
He's also an anarchist. I don't think he's in it for the money. It's also worth noting that several multibillion dollar organizations use the underlying software too. I'm saying he's highly experienced and has created a successful business. Even without VC funding!
So there's a difference:
Is your intent to build a high quality product that will make money?
Is your intent to make high income by selling a product?
Personally, I'd argue it's the job of the engineer to focus on the product. The money is the domain of the business people. I'd also argue that the former option is better for society and we're in a bad situation if the latter situation is dominating. The contention between business people and engineers is healthy. It creates balance. Our job is to make the product the best it can be, their job is to sell it. If we don't do our job they're more than happy to sell garbage as long as people will buy it. And remember, VCs don't care about you or the company past their exit. That's not healthy for something if you really care about the product. But it's fine if you care more about the money.
> 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.
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.
> 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.
Then continues:
> 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.”
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.)
That provides a baseline rationale and direction for organizational innovation. And for continuing to adapt it.
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.
not sure what about his animations captures my eyes, but i think he makes great use of 2D depth perception and color palettes.
https://www.youtube.com/watch?v=aMcJ1Jvtef0
> In this GDC 2016 talk, Terrible Toybox's Mark Ferrari discusses and demonstrate some of his techniques for drawing 8 bit game graphics, including his celebrated methods for use of color cycling and pallet shifting to create complex and realistic background animation effects without frame-animation
The lost art of color cycling - Animating with color
https://www.youtube.com/watch?v=LUbrzg21X9c
> Color cycling was born out of hardware restrictions but out of it came some beautiful artworks that characterized the 80s and 90s. In this video we will learn more about how this effect was produced and experience first hand the beautiful artwork created with it.
I dont think so. Having built some desktop applications and then brought them to mobile myself, it's not intuitive to know where the couplings are. For example, when bringing the app to mobile, someone may ask "Why didn't you encapsulate the microphone permission across all platforms up front?" Or "Why didn't you ensure this C library we use can compile on ARM?" These would be unreasonable abstractions to make for a desktop only application.
We know some of these things because mobile exists for a while now, but Moxie was talking about when smartphones just came out.
> 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.
There are unspoken constraints at play: size of the gamer audience, percent of gamers who rate and review games (ie. journalists & reviewers), number of developers willing to make something "insanely great", and even the total number of game concepts that actually exist.
When asking why systems develop the way they do, we can look at all possible constraints. This means ones that do and don'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.
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..
Yes: orgs should be better geared to feed engineering knowledge into devisions of what's achievable / what to do. There should be more cross-talk, just as among the many compartments of a human mind.
But there's a rich discussion to be had of how different constraints mean individuals and orgs excel at different things.
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't play enough games to know. What's the gamer consensus?
Case in point is the recently re-released Elder Scrolls IV: Oblivion. When it was released 20-something years ago, it received great reviews. I also loved the game. The re-release was basically the same game with modernized graphics - with the same bugs and all - and received much worse reviews. I watched a few Youtube videos playing it and thought "geez, how did I not see how crappy this game was 20 years ago".
The reason for this is that the same concept - an open world role-playing game with a massive world - has been redone in many other games and each new iteration of the concept has improved on it. As a result, the bar is now a lot higher for open world RPG games; if I play such a game nowadays, I expect to see good story design, good writing, good voice acting, etc. in addition to just being able to roam around in vast virtual forests.
I think that if the number of reviewers were to increase, the ratio between critically-acclaimed games and the total number of games coming out would still be very unimpressive.
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.
Well, yes, but I'd phrase this differently. To me, there is something uniquely unprofessional about software, and part of this unprofessionalism stems from our lack of understanding.
If you do get a computer science degree, congratulations! You have more knowledge than 90% of the people I've worked with in my 20-year career. But even then you only have the "book knowledge"; 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't updated to yet.
Software feels like magic because there's so much to know. Even for experts, knowing "how to do something right" isn't totally clear. I think the cause of the uncertainty is software engineering's lack of standardization.
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'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's safe to use. It's still not easy 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 can know exactly how to build a building the right way. Because of this, construction isn't magic. In fact, it's often derided as a job for people who aren't smart, yet you have to be fairly skilled to do any part of it well!
Software engineering still lacks the certainty that physical engineering figured out long ago. Apparently software isn'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 "engineers" who don't follow the protocol.
....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 (https://www.atlassian.com/agile), but those things require the boring, old, "normal" management to be done correctly first. This has been written about to death by people who'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.
I think it is widely viewed as important enough, and every serious attempt at a new language or many software tools involve massive efforts (when their ecosystems are considered).
But one challenge is, we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools, in a virtuous circle.
By the time that virtuous circle confirms that yes, A B and C are great improvements, its very difficult to take the next step and add D, E, and F that worked so well in another language.
It happens, but it tends to happen slowly and paid for with complexity that a new language with A, B, C, D, E and F at the start would not have had to pay. But getting a new language and ecosystem revved up is much harder than adding complexity. Until someone else with a great deal of passion and time takes another big gamble and succeeds.
Meanwhile, all that code in all those languages doesn't go away.
C++ complexity is where every language that never gives up, never surrenders, maintains backward compatibility, and continues folding in more good ideas, is slowly heading toward.
Its like trying to improve standards while building an "organically growing mountain terrain" type city, where the city has three main ground levels, covering vast areas of land, with smaller 2nd level areas on top of each, then smaller 3rd levels on all those 2nd level regions, etc. The different innovations happening in particular towers are very difficult for other towers built with other standards to adopt. But all the towers need to keep growing.
Someone says, lets start over with a new city, and it may be a much better city in many ways, but not all, and if enough people help they get a good enough first level up so more people start building there. But the same problem accrues.
Programming languages are just a raw material, like wood, or an alloy, or chemical. They have to be applied in a specific way to have a specific result. A "language" on its own doesn't matter. I could write you the same application in 5 different programming languages, just like I could build you the same building with 5 different raw materials.
Once you decide to use wood, you have to figure out how you're going to build with wood.
Again, in the olden days, this was a bespoke process, like it is today with programming. Are you going to timber-frame? Stick-frame? How tall will it be? Will you use wood joinery or metal fasteners? How will you reinforce it? How heavy will it be? Will you need special equipment or teams of people to move materials? Then you have to get your materials prepared; your beams cut to size, your metal fasteners of the right length, your mortises and tenons cut. Then finally you can assemble it all.
Compare that to programming. Again, you have to figure out how you're going to use the language. What modules you will use, what libraries, what software architecture, what APIs, what protocols, etc. Then you collect your materials and fit it all together.
The difference is this: with modern buildings, most of how you put the pieces together is already specified. An architect still needs to draw the plans up, but building it is pre-determined - not by the builders, but by the building code. You know for a wall plate you're going to need 10d nails. You know your floor joists must be 12, 16, or 24 inches on center, and you know how thick your subfloor needs to be for each. You do not deviate. For a given material, in a given place, for a given application, somebody has already determined how you will build it.
Another big problem with software is the lack of specialization. Most often I see teams of random software developers doing all kinds of things they're unqualified for. People who're clueless about system architecture, defining the architecture of the software. People building the applications without knowing what they will end up looking like. This is insane! Imagine if you just sent some random DIYers to build a house, with no plans, with no building code. The result would be an absolute mess. Of course they would need to stay employed for years, constantly fixing and bolting-on things to cover up their mess.
The "software world" has been an asylum run by the inmates for far too long. We don't need to constantly change languages. They're all about the same anyway! Rewrite an application from one language to another, and it just has a different set of bugs. The only reason it's done this way is we allow software developers unnecessary free reign, because we have no other choice, because it's just a guild of craftspeople building things however they want. Standardization should force a set of materials and a way of building, regardless of the personal whims of the programmers. The result may not be "fun" (which seems to be the primary priority of all programmers, over anything else), but it will result in lower cost, faster building, and more reliable results.
However, I‘m glad SWE isn’t standardized to the degree you describe.
It’s a field full of fads, deliberate inefficiencies and grandiose claims on shaky grounds. It’s also extremely diverse.