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.

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.

The original SV was focused on technical advancement and the current generation sees the technology as the vehicle to their goals.

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.

> 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.

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.

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.

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 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.

I don’t think there’s a formula for creativity. Sometimes it happens, sometimes it doesn’t.

We have many strong typists.

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.

[0] http://www.effectgames.com/demos/canvascycle/

https://getpocket.com/home

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.

That provides a baseline rationale and direction for organizational innovation. And for continuing to adapt it.

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.

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.

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.