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
I don't believe that 'profit' are the domain of business people anymore than astronomy is about telescope.
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.
I think you might be taking my words a bit to the extreme. Of course you still have to operate a business. I'm not trying to argue that and apologize if it came off that way.
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.
> Personally, I believe as engineers our focus should be on the product. The profits are the domain of the business people.
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.
This is as naive as you’re arguing the parent is. I agree you need to care about customers first, and make sure you’re solving their problem, but you absolutely do need to care about the code and if you treat it as always throwaway you can logically get to a justification for vibe coding. Of course you can get far witn these approaches, but they lead to unmaintainable messes which ultimately make it hard or impossible to actually do the thing you want: to deliver customer value.
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.
Anyone staring your career: maybe start focusing on making money and potentially lots of it from the very beginning. Because unless you are moxie or had an “exit” (he had an exit) you are doing it for the money. Don’t get distracted in the brouhaha of industry-speak and career-speak.
Doesn't explain why the biggest, most profitable tech companies also seem to have the most user-hostile products. I guess maybe the whole "The users and the customers are not the same people" thing...
> 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.
This is, in fact, what I'm arguing for.
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.
It is not. You can replace code, but you cannot just throw it away and continue to solve problems. That by definition makes it not worthless.
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
I don't get why you feel your positions are so far apart. Caring about customers and focusing on the product at their most different seem to be perspectives on the same thing, and then only if a really squint.
You switched the object of focus from profit to customers as if they were interchangeable. You are also using code and product/tech interchangeably, forgetting that there is a lot of effort put into architecture, design and usability.
Caring about the customer is caring about the product. Caring solely about profit is what enshitifies products.
I think you touch on a key point. Many people assume that developing tech involves VCs. My guess is that one can set technical advancement or market share gains.
The original SV was focused on technical advancement and the current generation sees the technology as the vehicle to their goals.
I never hated on Signal, on the contrary I recommend it too many people but I can say that the energy consumption on Android is in many cases abysmal for multiple years now and related issues in the Github issue tracker are being ignored. This is for me unacceptable for someone claiming to build high quality software and accepting my donations.
Signal spends a lot of time doing things it doesn't need to do.
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).
Signal isn’t good engineering though, it just happens to be a decent chat app, of which there is a long history. I only use it because some friends are on there.
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.
What is this FUD regarding lack of reproducible builds? The documentation about them is right here: "Signal has supported reproducible builds since Signal Android version 3.15.0, which was first released in March 2016." https://github.com/signalapp/Signal-Android/blob/main/reprod...
> 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.
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.
Your comment falls into the engineering superiority trap. Yes, one needs to understand how camera (or many other instruments) works, but only because different tweakable parameters are not completely orthogonal.
> 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.
> all they need to understand is which parameters affect output in what way.
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.
> If you had a digital camera that perfectly mimicked output of film camera
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.
> 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.
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.
Since you mentioned violin I’ll share my recent discovery.
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.
For anyone confused by this point perhaps watch some of the “why [movie] still looks like a billion bucks” videos on YouTube by Wolfcrow.
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 once heard a great question to illustrate this... When you are inspired by a painting, is this your first thought:
"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.
>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.
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.
The first half is this essay asserts that software engineering is like a science because "software development is actually full of discovery" and not the "engineering practice of combining and assembling what is available from the complex system of computing in order to manifest a given vision."
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.
I work as a swe in a company dominated by EEs and civil engineers, and while you’re not wrong in theory, the author’s point resonates a lot with me.
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.
> [complexity...] Author seems to imply that this is something unique to computing.
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.
It's both the ego and arrogance of the software developer.
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.
This criticism strikes me as lazy: it zeroes in on some casual introductory remarks made by the author which are intended to serve as a general guideline or frame of reference for understanding the concepts which follow, then invents a premise which is not in the article (that engineering doesn't contain discovery) and uses that to falsely demonstrate the weakness of the rest of the article.
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.
> The people who create software generally refer to themselves as software engineers
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.
This is an absolutely ridiculous take. If my more traditional engineering friend spends a day putting together plans based on existing documentation of parts, is he suddenly not doing engineering anymore? Do you expect him to run off to the supplier with a probe in hand and redo all their data sheets?
If your engineering friends only follow instructions and assemble things then they are not engineering. They are assembling. It takes less to follow instructions than it does to write the instructions.
I think there’s more to creativity than persistence and high intelligence. What about Docker, or Terraform? Super simple ideas that as far as I can tell, were not the result of persistence, and were not uniquely intellectually taxing to invent.
I don’t think there’s a formula for creativity. Sometimes it happens, sometimes it doesn’t.
Totally agree that the best stuff happens when vision and engineering evolve together. Some of the most creative breakthroughs I'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.
Innovation is nearly always bottom-up but eventually ossifies in the corporate structures that envelop it (Skype was a great example).
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.
>the real opportunity lies in understanding that you’re not bound by the conventions that have been passed down as “standard.”
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.
It's worth noting that Moxie is the same Moxie of Signal.
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.
It'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't be stored easily in a reliable way. I would have to host it myself and make some solution to find it.
in case it’s helpful for you, what i do when i find an article i really enjoy and want to keep to maybe revisit: i have a folder in my google drive for these with some sub-directories for light categorization, and then save a pdf copy of the article in there. don’t have to worry about a website going away in the future, and you get searchability
> 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.
Readit News
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?
[0] https://signal.org/
[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
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.
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.
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
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.
It is not. You can replace code, but you cannot just throw it away and continue to solve problems. That by definition makes it not worthless.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
Caring about the customer is caring about the product. Caring solely about profit is what enshitifies products.
The engineer’s job is to care deeply about the technical aspects of doing well by the customer.
Deleted Comment
The original SV was focused on technical advancement and the current generation sees the technology as the vehicle to their goals.
- 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.
Related issues:
https://github.com/signalapp/Signal-Android/issues/13704https://github.com/signalapp/Signal-Android/issues/12341https://github.com/signalapp/Signal-Android/issues/10336https://github.com/signalapp/Signal-Android/issues/9729
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
https://getpocket.com/home
> 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.