[HN Gopher] What makes a good engineer also makes a good enginee...
___________________________________________________________________
What makes a good engineer also makes a good engineering
organization (2024)
Author : kiyanwang
Score : 302 points
Date : 2025-05-19 05:26 UTC (2 days ago)
(HTM) web link (moxie.org)
(TXT) w3m dump (moxie.org)
| mrandish wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| tristor wrote:
| > 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.
| austin-cheney wrote:
| > 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 wrote:
| > Software employs a lot of typists.
|
| We have many strong typists.
| mdaniel wrote:
| What I want are more static typists
| et1337 wrote:
| 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 wrote:
| 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?
| austin-cheney wrote:
| 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.
| strken wrote:
| I'm sure the world's civil engineers will be pleased to
| learn that, since they already know the tensile strength of
| concrete and since they use surveyors to map a site,
| they're merely assembling bridges and freeways rather than
| engineering them.
| bluGill wrote:
| You don't need to be a civil engineer to design a single
| family house. The properties of the common materials like
| 2x4s are so well known that you need very little training
| to draw up a print that can be built - you look up in a
| chart how long a 2x12 can span and so long as you stay
| under that size your are okay.
|
| Now in a typical house the floor and roof use trusses
| that are engineered because in those areas engineering
| matters. Even then they are mostly taking a bunch of
| trusses already designed and putting their stamp on the
| system working.
|
| As buildings get larger/more complex though it becomes
| harder and harder to build the needed charts. Eventually
| you need a civil engineer to do a lot of calculation
| (with the help of a computer) because the building is
| different enough from anything before.
| 0xbadcafebee wrote:
| > 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), 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.
| Nevermark wrote:
| > Software engineering still lacks the certainty that physical
| engineering figured out long ago. Apparently software isn't
| important enough
|
| 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.
| 0xbadcafebee wrote:
| > 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
|
| Programming languages are just a raw material, like wood, or
| an alloy, or chemical. They have to be applied in a specific
| way to have a specific result. A "language" on its own
| doesn't matter. I could write you the same application in 5
| different programming languages, just like I could build you
| the same building with 5 different raw materials.
|
| Once you decide to use wood, you have to figure out _how_ you
| 're going to build with wood.
|
| Again, in the olden days, this was a bespoke process, like it
| is today with programming. Are you going to timber-frame?
| Stick-frame? How tall will it be? Will you use wood joinery
| or metal fasteners? How will you reinforce it? How heavy will
| it be? Will you need special equipment or teams of people to
| move materials? Then you have to get your materials prepared;
| your beams cut to size, your metal fasteners of the right
| length, your mortises and tenons cut. Then finally you can
| assemble it all.
|
| Compare that to programming. Again, you have to figure out
| how you're going to use the language. What modules you will
| use, what libraries, what software architecture, what APIs,
| what protocols, etc. Then you collect your materials and fit
| it all together.
|
| The difference is this: with modern buildings, most of _how_
| you put the pieces together is _already specified_. An
| architect still needs to draw the plans up, but _building it_
| is pre-determined - not by the _builders_ , but by the
| _building code_. You know for a wall plate you 're going to
| need 10d nails. You know your floor joists must be 12, 16, or
| 24 inches on center, and you know how thick your subfloor
| needs to be for each. You do not deviate. For a given
| material, in a given place, for a given application, somebody
| has already determined how you will build it.
|
| Another big problem with software is the _lack_ of
| specialization. Most often I see teams of random software
| developers doing all kinds of things they 're unqualified
| for. People who're clueless about system architecture,
| defining the architecture of the software. People building
| the applications without knowing what they will end up
| looking like. This is insane! Imagine if you just sent some
| random DIYers to build a house, with no plans, with no
| building code. The result would be an absolute mess. Of
| course they would need to stay employed for years, constantly
| fixing and bolting-on things to cover up their mess.
|
| The "software world" has been an asylum run by the inmates
| for far too long. We don't need to constantly change
| languages. They're all about the same anyway! Rewrite an
| application from one language to another, and it just has a
| different set of bugs. The only reason it's done this way is
| we allow software developers unnecessary free reign, because
| we have no other choice, because it's just a guild of
| craftspeople building things however they want.
| Standardization should force a set of materials and a way of
| building, regardless of the personal whims of the
| programmers. The result may not be "fun" (which seems to be
| the primary priority of all programmers, over anything else),
| but it will result in lower cost, faster building, and more
| reliable results.
| dgb23 wrote:
| Standardization is definitely important for foundational
| protocols and APIs.
|
| 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.
| nwlotz wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Would something lie Pocket work for you?
|
| https://getpocket.com/home
| eightys3v3n wrote:
| I was interested in trying this actually, I just haven't
| spent the time to set it up yet. :D
| abdullahkhalids wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| In SWE, software _is_ the plan.
|
| Anything before that is drawings on napkins.
| marcosdumay wrote:
| Yes, that's the point. The planning stage takes months to
| years, while the building stage takes seconds to hours and
| doesn't require any labor.
|
| There are no other engineering areas with a similar ratio.
| And yet, SWE planning and design does look like planning
| and design on any other area.
| yason wrote:
| > [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 N _N 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.
| TimByte wrote:
| Every engineering discipline has its own flavor of discovery,
| especially when you're working near the edges of what's known
| or what's been done before
| jhedwards wrote:
| 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.
| jt2190 wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| 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/
|
| [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 wrote:
| why do people hate on signal?
| johschmitz wrote:
| 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/12341
| https://github.com/signalapp/Signal-Android/issues/10336
| https://github.com/signalapp/Signal-Android/issues/9729
| guappa wrote:
| - They claim reproducible builds, but use a binary blob...
| which invalidates the whole concept.
|
| - 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.
| conradev wrote:
| Brian Acton put $100m into Signal and I thought that was
| the reason that they don't need funding
| aleph_minus_one wrote:
| I rather think the money for Signal comes (or originally
| came) from the CIA. Evidence:
|
| > Signal facing collapse after CIA cuts funding
|
| >
| https://english.almayadeen.net/articles/analysis/signal-
| faci...
| jajko wrote:
| If they had good access, why cut the funding? To subvert
| the security product where they actually have backdoor?
| jonstewart wrote:
| This is a pretty conspiratorial article...
|
| However, widely disseminating an app that supports secure
| e2e messaging can serve a positive purpose for the CIA in
| running its agents.
| godelski wrote:
| See? Mostly nerdy stuff. Like these complaints are weird to
| put side by side with how we'd critique all the big
| companies. Its not that we shouldn't critique them (we
| should) it is that it's weird when we are discussing big
| tech and act like companies like Signal, Mozilla, ffmpeg,
| or whatever aren't good models to look up to because they
| aren't perfect. Because right now the alternative is the
| status quo.
|
| I mean the critiques are mostly valid but wanted to point
| out they're mostly technical.
|
| I really wish the server was fully open. I feel like that
| could actually create a mixed federated ecosystem. At worst
| be optional, right? I can get where he's coming from (and
| now Meredith), but I think there's a lot of value in it and
| they've solved hard problems before. Even just the ideas of
| mesh nets in local areas could be a real win for privacy
| and security.
|
| Being a Linux user and signal user for quite some time I'm
| confused at that critique. What's hostile? That it's
| electron? I mean that does suck but I've used various open
| source desktop versions and some TUIs. No real issues so
| far. What am I missing?
|
| Generally the talk I hear about government money is
| implications of back doors. Just seems like they are more
| interested in getting encrypted communications into other
| people in other countries hands. At least that's my
| understanding of the mission of the organization that's
| funding them. They'd want that as secure as possible.
| Government isn't a single entity. If the complaint is
| morally taking money from the government, yeah it was a
| weird move. Kinda seems out of character. But not too
| crazy. Personally I'm okay if they aren't building weapons
| and there's no strings attached. My understanding is it's
| not enough money to justify that.
| guappa wrote:
| They're not really technical. If you say you do
| reproducible builds and you don't it's just...
| dishonesty?
|
| Like selling you no chemical fertilisers vegetables and
| then using them anyway.
|
| It's hostile because they want you to use their binary
| build... which you don't know if it corresponds to the
| source they have online. And can't verify due to the
| binary blob.
|
| edit: you trust the USA army to not ask any control in
| exchange for that money? Remember there's no reproducible
| builds really, and that installing via app store which is
| linked to an account is very easy to send vulnerable
| versions to journalists or whistleblowers.
| godelski wrote:
| I don't know how you say "not technical" and
| "reproducible builds" in the same breath.
|
| Look, I'm mostly with you. My point is that the issues we
| argue over are only things us nerds care about. Not the
| average person. > you trust the USA army
| to not ask any control in exchange for that money?
|
| Warrants suspicion, for sure. I stated so.
|
| From what I know, the money was not through the military.
| It was through Radio Free Asia, an organization suspected
| to have ties to the CIA. Notably, the CIA is concerned
| with _foreign_ targets, not at home. So like I argued, it
| is entirely reasonable for "the government" to want
| perfectly encrypted communication systems in the hands of
| people they want overthrowing a current regime while also
| not wanting that service to be used at home.
|
| The government isn't a single super intelligent entity
| working together. It is a fucking shit show of
| organizations (and sub-organizations) with entirely
| opposing goals.
|
| They're a non-profit... their books are open. If you are
| really concerned, switch to Molly. Or idk, use iMessage,
| WhatsApp, or Telegram. Because those have far less
| suspicion, right? Sure, you could use Matrix, but I can't
| get my grandma to use Matrix, but I can Signal. I'll take
| what I can get.
| maeil wrote:
| > - They claim openness but are actively hostile to linux
| distributions and f-droid.
|
| Yet take zero action against TeleMessage.
| Ragnarork wrote:
| > - There's a lot of allegations that they don't need VCs
| because they have backing from the USA army.
|
| Citation needed. Strange allegations (and from whom?) when
| the pentagon itself has discouraged using Signal in an
| official capacity...[0]
|
| [0]https://abcnews.go.com/Business/what-is-signal-
| messaging-enc...:
|
| > The Pentagon's internal watchdog criticized a former
| official's use of the Signal app in 2021, calling it a
| breach of the department's "records retention policies" and
| an unauthorized means of communicating sensitive
| information.
|
| > "Signal is not approved by the DoD as an authorized
| electronic messaging and voice-calling application," the
| report asserted, adding that "the use of Signal to discuss
| official DoD information does not comply with Freedom of
| Information Act requirements and DoD's records retention
| policies."
| pphysch wrote:
| The highest military council in the country uses Signal
| to communicate. I think violating FOIA is probably part
| of the appeal. Or they use that modified Israeli client
| that stores messages to address those concerns.
| godelski wrote:
| They don't use Signal. They use an app that wraps around
| Signal. There is in fact a difference. Specifically
| because the purpose of that app is to do exactly what
| you're accusing Signal of doing. If Signal already did
| this... why would they pay for the other app?
| pona-a wrote:
| There also was this one controversy they had with F-Droid.
| To be on F-Droid, you have to let them build the binaries,
| because otherwise they'd be shipping untrusted blobs. They
| demanded an exemption and got promptly denied, so there's
| that. Their official client also uses Google's push
| notification services, breaking on deGoogled ROMs. And to
| top that off, their Git is updated in giant commits like
| "Released verison X", which makes independent code review
| challenging. And they require a phone number, which goes
| against some people's threat model.
| Vinnl wrote:
| > - They claim federation is impossible... yet matrix has
| it.
|
| I believe the claim was that it's hard to adapt to changing
| markets _and_ be federated [1]. Comparing Signal 's market
| share to Matrix's is obviously not a direct cause-and-
| effect, but Matrix hasn't yet proven that you can get mass
| adoption that way.
|
| > - They claim openness but are actively hostile to linux
| distributions and f-droid.
|
| I'm too lazy to find the specific GitHub comment, but IIRC
| there was a specific list of features they'd need to
| actively support F-Droid. It is now available in the
| Guardian Project's F-Droid repository though [2].
|
| [1] https://signal.org/blog/the-ecosystem-is-moving/
|
| [2] https://guardianproject.info/apps/org.thoughtcrime.secu
| resms...
| LtWorf wrote:
| > but Matrix hasn't yet proven that you can get mass
| adoption that way.
|
| Neither has signal. I can contact more people with GPG
| than with signal.
| Vinnl wrote:
| No, but Signal doesn't have to prove that centralised
| services can be successful: other services have already
| done that for them.
|
| At the same time, it has reached far more regular users
| than Matrix has. I believe market penetration is at about
| 15% here in the Netherlands, which is a ways off from
| WhatsApp, but a pipe dream for Matrix.
| dogecoinbase wrote:
| > They claim full open source but for several years they
| did not release the server.
|
| Specifically, they didn't publish the source for their
| server-side from 20 April 2020 to 6 April 2021 [0] while
| they secretly added a cryptocurrency payment system to
| which Moxie was a paid technical advisor [1], which Moxie
| denied they were doing in January 2021 [2].
|
| 0: https://www.androidpolice.com/2021/04/06/it-looks-like-
| signa... (source was published shortly after the
| publication of that article)
|
| 1: https://news.ycombinator.com/item?id=26715013 (comment
| from founder of MobileCoin)
|
| 2: https://www.theverge.com/22249391/signal-app-abuse-
| messaging...
| XorNot wrote:
| 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).
| kortilla wrote:
| 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.
| tuukkah wrote:
| 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...
| kortilla wrote:
| Those steps assume you can get images pulled off of your
| Android device that are actually running. This is the
| problem with all of these ecosystems.
|
| Regardless, those instructions are useless for iPhone:
| https://community.signalusers.org/t/add-reproducible-
| builds-...
| LtWorf wrote:
| If you include a binary blob that you can't verify in the
| steps... what's exactly the point to obtain an identical
| artifact?
| kiba wrote:
| 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.
| godelski wrote:
| 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.
| kingkongjaffa wrote:
| > 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.
| yladiz wrote:
| 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.
| makeitdouble wrote:
| I'd argue if you care about your customers, vibe coding
| will be a no-go. Most of us aren't against it not on
| principle, but because it's just too risky or too
| inefficient to bring real value in most applications.
|
| If someday it produces messy but actually reliable code my
| opinion will change, but at this point, it's just too early
| (not saying it will ever work, but one can hope)
| spjt wrote:
| 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...
| gchamonlive wrote:
| 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.
| crossroadsguy wrote:
| 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.
| resize2996 wrote:
| No? I could do several other things if I just wanted money.
| I do tech work because that is what I am called to do.
| pammf wrote:
| Such as?
| godelski wrote:
| The business people sure seem to make a lot more money...
| I can tell you that I have multiple family members that
| work in sales and make boatloads. My cousin spends at
| least 15hrs a week playing golf (something he really
| likes) on the company dime and getting fancy meals.
| That's also while making over $300k/yr. Others don't play
| golf but still do the lunches and meals, getting paid
| similarly. I'd say that this is a much easier work life
| than what we do...
|
| Certainly you have non-techncal managers that are making
| more money than you and do you think they do more work?
| Certainly some do but I doubt all.
| shawabawa3 wrote:
| > If you're just starting your career I'm begging you not to
| laser focus on coding widgets better for the sake of it.
|
| 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
| godelski wrote:
| I agree. I'm a bit confused by the response as well. Idk
| what I need to clarify but I'm open to suggestions.
|
| I was hoping that dichotomy of sacrificing product for
| profit or profit for product would help but I'm unsure.
| Multiple people seemed to have misunderstood but I'm also
| unsure what was confusing. Frankly I'm having a hard time
| understanding how they reached such a dramatically
| different interpretation.
| skeeter2020 wrote:
| 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.
| bluGill wrote:
| > All code is throwaway,
|
| 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.
| mystified5016 wrote:
| Yes, this is the exact opposite viewpoint parent was talking
| about. You're taking the MBA stance here.
| bee_rider wrote:
| I don't really see how you guys are in opposition. They said
| to focus on the product, not to focus on the code.
|
| The engineer's job is to care deeply about the technical
| aspects of doing well by the customer.
| godelski wrote:
| > 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
| detourdog wrote:
| 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.
| thenoblesunfish wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| vincnetas wrote:
| 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 wrote:
| 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 wrote:
| 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.
| macleginn wrote:
| > 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 wrote:
| 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/ocean.gif
| andersource wrote:
| I too think they're gorgeous. They're by Mark Ferrari, you can
| find more here[0].
|
| [0] http://www.effectgames.com/demos/canvascycle/
| 4ggr0 wrote:
| 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.
| immibis wrote:
| The waterfall is by Mark J Ferrari.
| https://www.markferrari.com/image-archives
| __abc wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| golly_ned wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-21 23:01 UTC)