10 ms·

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

337 points by kiyanwang 1y ago

mrandish 1y ago
> 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.
- abtinf 1y ago
  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.
  - rented_mule 1y ago
    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.
    - guappa 1y ago
      Painters in the renaissance were making their own paint most of the time. They were not just buying whatever was available and hoping for the best.
      - bluGill 1y ago
        They tended to use a lot of things like lead. While I could probably duplicate their methods, it would (like it did to them) poison me. However duplicating the paint won't make me an artist. Practice painting would make me an artist and buying paint would allow more time to practice. Practice would also let me learn how modern safe paints work and so I could make something that looks like what they could do with modern paints, or I could create something they could not for lack of ability to get that color/shine/whatever (I'm not a painter and don't know the terms they would use).
    - tetha 1y ago
      > 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.
  - protocolture 1y ago
    >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.
  - SoftTalker 1y ago
    Yes but at some point you can stop understanding how it works. Maybe it wasn't the best example but I think picking it apart misses the larger point.
    - whatnow37373 1y ago
      Yeah but any abstraction can be made to work if it remains sufficiently abstract. 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).
- xlii 1y ago
  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. But I still couldn’t build one..
- friendzis 1y ago
  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.
  - guappa 1y ago
    > 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. It's not the same at all.
  - mrandish 1y ago
    > 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.
fdadsfdsd 1y ago
[flagged]
faffdsf 1y ago
[dead]
austin-cheney 1y ago
> 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. If you hire a bunch of clowns you get a circus.
- drewcoo 1y ago
  > Software employs a lot of typists. We have many strong typists.
  - mdaniel 1y ago
    What I want are more static typists
- et1337 1y ago
  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.
- strken 1y ago
  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?
deleted 1y ago
[deleted]
0xbadcafebee 1y ago
> I think there is something uniquely magical about software, and part of that magic might stem from this tension in how we define it. 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 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.
nwlotz 1y ago
Engineering often supplies the potential energy fueling vision and vice versa. ARPANET was very specifically engineered with the vision of a network that could survive nuclear attack. Then it evolved into the internet, which fueled a new vision of collaboration and discovery for students, hackers, and researchers. Who in turn created systems that became new business models, and the cycle goes on.
eightys3v3n 1y ago
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.
- kr2 1y ago
  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
- Cipater 1y ago
  Would something lie Pocket work for you? https://getpocket.com/home https://getpocket.com/home
  - eightys3v3n 1y ago
    I was interested in trying this actually, I just haven't spent the time to set it up yet. :D
  - eightys3v3n 1y ago
    Oh, Pocket is shutting down. https://support.mozilla.org/en-US/kb/future-of-pocket https://support.mozilla.org/en-US/kb/future-of-pocket I was actually referring to Link Warden. I am now trying it out :D
abdullahkhalids 1y ago
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.
- oreally 1y ago
  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.
- pyrale 1y ago
  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.
  - sdeframond 1y ago
    In SWE, software is the plan. Anything before that is drawings on napkins.
jt2190 1y ago
The author writes: > 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.)
- Nevermark 1y ago
  The corollary of "Software systems reflect the organizational structure they are developed in", would be "Design your organization to match the structure of the software you want." That provides a baseline rationale and direction for organizational innovation. And for continuing to adapt it.
coderintherye 1y ago
>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.
- godelski 1y ago
  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.
mikelinsi 1y ago
Thanks for sharing! I had never really thought about the difference in meaning between the words Science and Engineering in this context. 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.
godelski 1y ago
This is the Moxie that created Signal.[0] 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/ 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
- NL807 1y ago
  why do people hate on signal?
  - johschmitz 1y ago
    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. Related issues: https://github.com/signalapp/Signal-Android/issues/13704 https://github.com/signalapp/Signal-Android/issues/13704 https://github.com/signalapp/Signal-Android/issues/12341 https://github.com/signalapp/Signal-Android/issues/12341 https://github.com/signalapp/Signal-Android/issues/10336 https://github.com/signalapp/Signal-Android/issues/10336 https://github.com/signalapp/Signal-Android/issues/9729 https://github.com/signalapp/Signal-Android/issues/9729
  - 1y ago
thenoblesunfish 1y ago
The chart of games vs highly rated games, as evidence of more stuff, but not more good stuff, is thought provoking. 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?
- callingbull 1y ago
  Not a gamer, but it seems "highly rated" is a matter of attention and status, and the number would increase with the population not with the overall number of games.
- vjk800 1y ago
  There are games that are still good 30 years after the publication and there are games that were good then but seem unimpressive now. The latter category often includes games that did something new and innovative for the time it was published, but has since then become a standard mechanic in games. 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.
vaylian 1y ago
This seems to be the key paragraph: > 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.
deleted 1y ago
[deleted]
vincnetas 1y ago
If you take film maker comparison with game engine from TFA. i would say there is no difference here. As cameras got more and more accessible (paralell to game engine) more and more people started recording videos (making games). This does not mean that we have corresponding increase in oscars distributed. We just got youtube filled with millions of videos like we have steam filled with lots of indie game developers.
TimByte 1y ago
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.
- notarobot123 1y ago
  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. Creative destruction is such a beautiful thing.
  - TimByte 1y ago
    Creative destruction is beautiful but only when you're not the one getting disrupted :)
macleginn 1y ago
> 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. 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.
4ggr0 1y ago
The two landscape GIFs, or I guess color cycles on this page are absolutely beatuiful, wow. Don't remember the last time I was stuck looking at animations, just because they're so satisfying to look at. Not even sure why they seem so special to me... https://moxie.org/blog/images/falls-colorcycling.gif https://moxie.org/blog/images/falls-colorcycling.gif https://moxie.org/blog/images/ocean.gif https://moxie.org/blog/images/ocean.gif
- andersource 1y ago
  I too think they're gorgeous. They're by Mark Ferrari, you can find more here[0]. [0] http://www.effectgames.com/demos/canvascycle/ http://www.effectgames.com/demos/canvascycle/
  - 4ggr0 1y ago
    oah, thanks a lot! love his artstyle, gotta look him up :) not sure what about his animations captures my eyes, but i think he makes great use of 2D depth perception and color palettes.
  - nthingtohide 1y ago
    8 Bit & '8 Bitish' Graphics-Outside the Box https://www.youtube.com/watch?v=aMcJ1Jvtef0 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 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.
    - 4ggr0 1y ago
      amazing, i love interesting rabbit-holes into the past initiated by engaging with HN :D immediately put them on watch later.
__abc 1y ago
Weird, maybe it's because I'm mostly gray haired at this point, but I find myself referring to my profession as "Computer Science" more and more as time passes.
jsbg 1y ago
It's a good point about confirmation and survivorship biases. However, the Skype example is really an example of what happens when your codebase has coupling where there shouldn't be. Encapsulation is a foundational concept in software engineering for a reason. That doesn't mean that it's not useful to know, e.g. the inner workings of your database. But it's unreasonable to expect that anyone at your software company can know more than a surface amount about what other teams do.
- yellow_lead 1y ago
  > However, the Skype example is really an example of what happens when your codebase has coupling where there shouldn't be. 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.
curtisszmania 1y ago
[dead]
shitpostbot 1y ago
[dead]
golly_ned 1y ago
The point about how increasing the number of Steam games published didn't increase the number of critically acclaimed Steam games, and therefore, volume decreases average quality, is very weird. It's the wrong conclusion to draw when an alternative, like the volume of reviews didn't increase along with the number of games published, exists.
- nuredini 1y ago
  Do you mean that there aren't that many critically-acclaimed games nowadays (relative the the number of games coming out) because there aren't enough reviewers? I can't really think of many great, recent games that haven't had enough reviews or the attention they deserved. Sure, that might be some cases; but, in general, it just feels like we don't read more positive reviews because we're not getting that many great games. 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.
hermitShell 1y ago
It would be great to put Carmack and Moxie in a room to discuss low level software.
cadamsdotcom 1y ago
Great read. One thing that stood 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.

337 points by kiyanwang 1y ago

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

abtinf 1y ago
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.
- rented_mule 1y ago
  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.
  - guappa 1y ago
    Painters in the renaissance were making their own paint most of the time. They were not just buying whatever was available and hoping for the best.
    - bluGill 1y ago
      They tended to use a lot of things like lead. While I could probably duplicate their methods, it would (like it did to them) poison me. However duplicating the paint won't make me an artist. Practice painting would make me an artist and buying paint would allow more time to practice. Practice would also let me learn how modern safe paints work and so I could make something that looks like what they could do with modern paints, or I could create something they could not for lack of ability to get that color/shine/whatever (I'm not a painter and don't know the terms they would use).
  - tetha 1y ago
    > 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.
- protocolture 1y ago
  >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.
- SoftTalker 1y ago
  Yes but at some point you can stop understanding how it works. Maybe it wasn't the best example but I think picking it apart misses the larger point.
  - whatnow37373 1y ago
    Yeah but any abstraction can be made to work if it remains sufficiently abstract. 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).
xlii 1y ago
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. But I still couldn’t build one..
friendzis 1y ago
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.
- guappa 1y ago
  > 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. It's not the same at all.
- mrandish 1y ago
  > 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.

fdadsfdsd 1y ago

[flagged]

faffdsf 1y ago

[dead]

austin-cheney 1y ago

> 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. If you hire a bunch of clowns you get a circus.

drewcoo 1y ago
> Software employs a lot of typists. We have many strong typists.
- mdaniel 1y ago
  What I want are more static typists
et1337 1y ago
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.
strken 1y ago
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?

deleted 1y ago

[deleted]

0xbadcafebee 1y ago

> I think there is something uniquely magical about software, and part of that magic might stem from this tension in how we define it. 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 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.

nwlotz 1y ago

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

eightys3v3n 1y ago

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.

kr2 1y ago
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
Cipater 1y ago
Would something lie Pocket work for you? https://getpocket.com/home https://getpocket.com/home
- eightys3v3n 1y ago
  I was interested in trying this actually, I just haven't spent the time to set it up yet. :D
- eightys3v3n 1y ago
  Oh, Pocket is shutting down. https://support.mozilla.org/en-US/kb/future-of-pocket https://support.mozilla.org/en-US/kb/future-of-pocket I was actually referring to Link Warden. I am now trying it out :D

abdullahkhalids 1y ago

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.

oreally 1y ago
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.
pyrale 1y ago
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.
- sdeframond 1y ago
  In SWE, software is the plan. Anything before that is drawings on napkins.

jt2190 1y ago

The author writes: > 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.)

Nevermark 1y ago
The corollary of "Software systems reflect the organizational structure they are developed in", would be "Design your organization to match the structure of the software you want." That provides a baseline rationale and direction for organizational innovation. And for continuing to adapt it.

coderintherye 1y ago

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

godelski 1y ago
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.

mikelinsi 1y ago

Thanks for sharing! I had never really thought about the difference in meaning between the words Science and Engineering in this context. 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.

godelski 1y ago

This is the Moxie that created Signal.[0] 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/ 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

NL807 1y ago
why do people hate on signal?
- johschmitz 1y ago
  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. Related issues: https://github.com/signalapp/Signal-Android/issues/13704 https://github.com/signalapp/Signal-Android/issues/13704 https://github.com/signalapp/Signal-Android/issues/12341 https://github.com/signalapp/Signal-Android/issues/12341 https://github.com/signalapp/Signal-Android/issues/10336 https://github.com/signalapp/Signal-Android/issues/10336 https://github.com/signalapp/Signal-Android/issues/9729 https://github.com/signalapp/Signal-Android/issues/9729
- 1y ago

thenoblesunfish 1y ago

The chart of games vs highly rated games, as evidence of more stuff, but not more good stuff, is thought provoking. 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?

callingbull 1y ago
Not a gamer, but it seems "highly rated" is a matter of attention and status, and the number would increase with the population not with the overall number of games.
vjk800 1y ago
There are games that are still good 30 years after the publication and there are games that were good then but seem unimpressive now. The latter category often includes games that did something new and innovative for the time it was published, but has since then become a standard mechanic in games. 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.

vaylian 1y ago

This seems to be the key paragraph: > 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.

deleted 1y ago

[deleted]

vincnetas 1y ago

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

TimByte 1y ago

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.

notarobot123 1y ago
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. Creative destruction is such a beautiful thing.
- TimByte 1y ago
  Creative destruction is beautiful but only when you're not the one getting disrupted :)

macleginn 1y ago

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

4ggr0 1y ago

The two landscape GIFs, or I guess color cycles on this page are absolutely beatuiful, wow. Don't remember the last time I was stuck looking at animations, just because they're so satisfying to look at. Not even sure why they seem so special to me... https://moxie.org/blog/images/falls-colorcycling.gif https://moxie.org/blog/images/falls-colorcycling.gif https://moxie.org/blog/images/ocean.gif https://moxie.org/blog/images/ocean.gif

andersource 1y ago
I too think they're gorgeous. They're by Mark Ferrari, you can find more here[0]. [0] http://www.effectgames.com/demos/canvascycle/ http://www.effectgames.com/demos/canvascycle/
- 4ggr0 1y ago
  oah, thanks a lot! love his artstyle, gotta look him up :) not sure what about his animations captures my eyes, but i think he makes great use of 2D depth perception and color palettes.
- nthingtohide 1y ago
  8 Bit & '8 Bitish' Graphics-Outside the Box https://www.youtube.com/watch?v=aMcJ1Jvtef0 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 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.
  - 4ggr0 1y ago
    amazing, i love interesting rabbit-holes into the past initiated by engaging with HN :D immediately put them on watch later.

__abc 1y ago

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

jsbg 1y ago

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

yellow_lead 1y ago
> However, the Skype example is really an example of what happens when your codebase has coupling where there shouldn't be. 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.

curtisszmania 1y ago

[dead]

shitpostbot 1y ago

[dead]

golly_ned 1y ago

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

nuredini 1y ago
Do you mean that there aren't that many critically-acclaimed games nowadays (relative the the number of games coming out) because there aren't enough reviewers? I can't really think of many great, recent games that haven't had enough reviews or the attention they deserved. Sure, that might be some cases; but, in general, it just feels like we don't read more positive reviews because we're not getting that many great games. 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.

hermitShell 1y ago

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

cadamsdotcom 1y ago

Great read. One thing that stood 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.