[HN Gopher] Software designers, not engineers: An interview from...
       ___________________________________________________________________
        
       Software designers, not engineers: An interview from alternative
       universe
        
       Author : spdegabrielle
       Score  : 116 points
       Date   : 2021-04-20 11:45 UTC (11 hours ago)
        
 (HTM) web link (tomasp.net)
 (TXT) w3m dump (tomasp.net)
        
       | ilaksh wrote:
       | Makes a lot of sense to me, most of it. I think they idea that
       | you can't learn important software engineering/designing lessons
       | from a book is overstated though.
       | 
       | But it is true that most of the existing books probably don't
       | include some of the types of case studies and lessons that you
       | would get from a job. But I think that textbooks should simulate
       | those things with exercises. Of course a textbook can't include
       | real dynamics or interactions but it's not true that it's
       | impossible for some of those lessons to be in a book or at least
       | touched on.
       | 
       | I mean, a textbook could actually emphasize things like digging
       | in and iterating to really understand the problem in depth. The
       | criticality and difficulty of understanding the problem and
       | finding the right framing for the problem, realizing that is
       | something that should be deliberately shaped to enable the
       | solution.
       | 
       | To me the most challenging thing has always been the power
       | imbalance between myself and the managers or users who are
       | incorrectly framing the problems, and the struggle to negotiate
       | an adequate problem definition that will enable a good outcome.
        
       | Hammershaft wrote:
       | This was great!
        
       | finnthehuman wrote:
       | Software spends too much of it's self-reflection time looking
       | wistfully at the cool kids over in the arts.
        
         | Datenstrom wrote:
         | I have also worked close to electrical and mechanical
         | engineering for a long time. Apparently you have not worked
         | around rapid prototyping of robotics to think this [1].
         | 
         | [1]: https://m.xkcd.com/2128/
        
           | [deleted]
        
         | atoav wrote:
         | I have a very diverse background in these regards:on the
         | creative side I was freelance designer and have a MA of Arts,
         | on the engineering side I design electronic circuits, program,
         | work in VFX.
         | 
         | I guess many devs dream of expressing themselves with
         | programming, just like many film makers, painters, artists
         | dream of expressing themselves with their craft. But what many
         | don't realise, is that after a certain degree of mastery, you
         | _know_ that certain topics demand a certain handling. It
         | becomes less about you, it becomes more about that fascinating
         | aspect of reality you are dealing with.
         | 
         | Whether that fascinating aspect is a certain mood you wanna
         | express, a certain story you wanna tell or a certain problem
         | you wanna solve and create a beautiful elegant solution for is
         | not that different to me.
         | 
         | However: people who always make it about themselves instead of
         | looking at the topics they deal with will rarely create things
         | of lasting value, neither in art or design, nor in engineering.
         | If you chose that framework because you thought it was cool,
         | not because the problem you are solving demanded it, you are
         | still learning and not creating the solution the problem
         | deserves.
        
         | finnthehuman wrote:
         | For a decade I've mostly worked on the kind of products that
         | require operating in close proximity to mechanical, electrical
         | and system engineers. It's thoroughly and consistently
         | disabused me of the notion I see in software-centric areas that
         | software is uniquely creative such that it's different than
         | other "engineering" disciplines. They are just as - if not more
         | - creative within their domains.
         | 
         | Software does have lower commercial expectations in the areas
         | of reliability and quality, and that does seep into the
         | practices you see in design and implementation. But I don't
         | think it produces a difference in kind.
        
           | dcolkitt wrote:
           | You have to question if you are dealing with an unbiased
           | subset of mechanical and electrical engineers. That kind of
           | interdisciplinary collaboration usually occurs in some sort
           | of cutting edge field.
           | 
           | The typical mechanical engineer is calculating HVAC loads for
           | commercial buildings, not working on robotics. In contrast
           | Google is probably only hiring a mechanical engineer for work
           | that's the tip of the spear.
           | 
           | (In fairness this also goes the other way. The software
           | engineers working on yet another internal corporate CRUD app
           | are largely invisible to the typical physical engineer.)
        
           | quesera wrote:
           | All engineering work is intensely creative.
           | 
           | There are tech jobs which are not creative, of course, but
           | they are not "engineering", whatever title they may have.
        
           | robocat wrote:
           | > Software does have lower commercial expectations in the
           | areas of reliability and quality
           | 
           | Even though I take care, I still end up with non-software
           | things that:
           | 
           | * quickly break
           | 
           | * have bizarre unintuitive quirks of usability
           | 
           | * visual form has been given preference over function
           | 
           | * Low quality even though not cheap
           | 
           | * require hacks to fix them (glue, labels, training, tape,
           | modifications), and often cannot be fixed.
           | 
           | I would love to see some metric of reliability and quality be
           | applied to our everyday things and compare it to our everyday
           | software.
        
         | Apocryphon wrote:
         | It's part of the mythos.
         | 
         | https://www.youtube.com/watch?v=KlI1MR-qNt8
        
       | TobySKT wrote:
       | eLearning Website Development: Top 12 Tips for Creating a
       | Successful Marketplace With a mass of information you can search
       | online, it is not surprising the Internet has become a self-
       | education mecca. The recent coronavirus pandemic has contributed
       | to the rapid adoption of e-learning, even making it a necessary
       | safety measure. What does this mean? It means that the best time
       | to create elearning website is now.
       | https://steelkiwi.com/blog/e-learning-website-development-to...
        
       | robertlagrant wrote:
       | I don't see how the other universe ever designed CPUs, RAM, or
       | desktop computers without the specific end goal in mind. Perhaps
       | they're drowning in purpose-built hardware?
        
         | meheleventyone wrote:
         | The conceit isn't that there are no engineers or engineering
         | disciplines just the focus for software development as a
         | discipline was design rather than engineering.
        
       | aranchelk wrote:
       | > When you're solving a problem, even as you get to a more
       | technical level, you always keep in mind why you are solving it.
       | I noticed that software engineers in your universe often ignore
       | this. You fixate on some technical solution and then completely
       | forget what is the context in which you're building it.
       | 
       | Excellent, you've just described a horrible engineer.
       | 
       | An article poor in both concept and execution. A painful read.
        
       | seemaze wrote:
       | Often overlooked, the core tenet of engineering is public safety.
       | This is why professional engineers are required to obtain a
       | license, register in their practicing jurisdiction, and are held
       | liable if their work fails to achieve a prescribed consensus of
       | acceptability.
       | 
       | Imagine if software was held to the same level of scrutiny..?
       | Software is carpentered, some is designed, and little is actually
       | engineered.
       | 
       | Engineers don't fail forward, early, fast, or often. They don't
       | move fast and break things. Not engineering software is great,
       | because if you had to pull permits to build your software, the
       | web would still look like 1996 and my phone would have a keypad.
        
         | IvanAchlaqullah wrote:
         | > Imagine if software was held to the same level of scrutiny..?
         | Software is carpentered, some is designed, and little is
         | actually engineered.
         | 
         | This is why I never approve criminalizing software bugs.
         | 
         | Imagine if you committed some codes, then turnout codes in that
         | commit can be exploited by hacker 10 years later, are you
         | willing to be imprisoned for creating codes that "fails to
         | achieve a prescribed consensus of acceptability" ?
        
         | atoav wrote:
         | This is my pet peeve with many software developers. They
         | _develope_ software like a photo lab technician develops a roll
         | of film: Let 's see what result we get now, if it is
         | problematic move to the next thing.
         | 
         | I think bot good engineering and good desin practise is the
         | opposite of developing a picture. It is really iterative
         | process, trying to factor in as many of the important aspects
         | as possible and try to get the one solution where all of these
         | aspects don't fight each other, but strengthen each other.
         | 
         | Many software developers I met are just focused at what
         | framework/language/design pattern/etc they are going to throw
         | at the next problem. Of course that is all exiting, but what if
         | the thing you are tackeling could be solved so much better, if
         | you just killed your darlings and tried to find the _best_
         | solution?
         | 
         | Sure you cannot learn $framework you were curious about on the
         | way, but finding elegant and good solutions is itself a skill
         | that needs training.
        
         | jonas21 wrote:
         | That's assuming there'd be a web or mobile phones at all.
         | 
         | I'd imagine that all software would still be run on a
         | mainframe, where every change could be carefully audited and
         | signed off on.
        
         | bob1029 wrote:
         | I have always treated my professional work with software as
         | very serious business.
         | 
         | We aren't developing anything with direct life-safety
         | consequences, but we are dealing with PII and other people's
         | money. I see no reason to relax due diligence on anywhere along
         | this spectrum. It's either correct or its not, and the
         | consequences for getting something wrong are universally bad
         | for all involved.
         | 
         | Now, I also strongly believe in the idea that software
         | development is inherently an art form. The nuance is that
         | within this art form, there are still very rigid conceptual
         | frameworks you need to work with. For instance, designing the
         | UI for any application is more-or-less a pure art form.
         | Developing the SQL schema backing that UI is arguably something
         | that is 100% deterministic and can have mathematical proofs
         | established which prove its correctness one way or another.
         | 
         | The key to the success of any software project is blending
         | these two worlds together in a sustainable and responsible way.
        
           | Atixx wrote:
           | > Developing the SQL schema backing that UI is arguably
           | something that is 100% deterministic and can have
           | mathematical proofs established which prove its correctness
           | one way or another.
           | 
           | Maybe I'm misinterpreting your point here, but the way you
           | create the different models, compose the modules which will
           | use them and represent the abstract entities and processes
           | that execute when that UI is interacted with can be done in
           | many ways, both well and very badly, depending on the
           | measurements you take to evaluate it. All the different terms
           | to consider 'clean', 'maintainable', 'readable', etc. code, I
           | consider to also be somewhat abstract to define in an art-
           | type of way.
           | 
           | The reason I mention this is that the 'visual design' of the
           | UI is not so much a software work as much as a UI/UX designer
           | work. Bringing that design to life in an application using
           | actual code and not a design tool is where the same
           | principles I mentioned above come into play, even if the
           | actual 'visual design' was completed by a different person
           | which might not code, or the same dev.
        
       | mrdonbrown wrote:
       | I recently did an interview on this topic [1] and I was surprised
       | to hear the designer say, "If the developer tells me to design
       | whatever and they'll build it, that is a huge fail". I kinda
       | assumed designers were in their own world where we (developers)
       | met at the DMZ, but his point is we are all part of the same
       | team. The more I thought about it, the more sense it made.
       | 
       | [1] https://www.youtube.com/watch?v=0Oi913i2mCA
        
       | rogers18445 wrote:
       | Not a single mention of data structures. It really is the heart
       | of software when done properly. You can often tell if someone is
       | a subscriber of that view depending on where they place their
       | data structures in the source files.
       | 
       | Once the data layout is properly designed, the data
       | transformations required become clear and the rest of grunt work.
        
         | monocasa wrote:
         | > Show me your flowcharts and conceal your tables, and I shall
         | continue to be mystified. Show me your tables, and I won't
         | usually need your flowcharts; they'll be obvious.
         | 
         | ~ Fred Brooks
         | 
         | > I will, in fact, claim that the difference between a bad
         | programmer and a good one is whether he considers his code or
         | his data structures more important. Bad programmers worry about
         | the code. Good programmers worry about data structures and
         | their relationships.
         | 
         | ~ Linus Torvalds
        
         | robotpony wrote:
         | > "Data dominates. If you've chosen the right data structures
         | and organized things well, the algorithms will almost always be
         | self-evident. Data structures, not algorithms, are central to
         | programming." ~ Rob Pike
        
       | abeppu wrote:
       | I find it odd that this doesn't make mention of civil engineering
       | or construction engineering in the architecture analogy. Like,
       | absolutely the artificial world should be designed with
       | objectives like appropriateness, but that doesn't mean you don't
       | need to have people whose roles focus on the technical approach
       | to carrying out a design.
       | 
       | We _have_ product design experts and processes for software
       | products, but that's not a reason to not have engineers. And as
       | to why they're not celebrities typically ... I think that's also
       | in part because the companies that produce software want to
       | control their brands. This isn't a threat for architects; BMW
       | doesn't lose anything by us knowing that Zaha Hadid designed a
       | building for them. If she had then designed a building Toyota,
       | that wouldn't have been a problem. Their value proposition isn't
       | about the building they work from. But if you knew and cared
       | about the name of the specific designer behind your favorite
       | software product, and they left the company ... that would be a
       | problem for that company. Part of the prestige associated with
       | their core offering is able to walk away.
        
       | meheleventyone wrote:
       | It's amazing how much this imagined interview matches up with my
       | experiences working as a game designer. You could lift a lot of
       | this, apart from the wild fame pieces straight from talking about
       | game design where the designer is also heavily involved in
       | implementation.
        
       | antipaul wrote:
       | Ideas seem to resonate with Fred Brooks, of "Good design comes
       | from good designers" fame.
        
       | catern wrote:
       | The conceit of this article reminds me of
       | http://ngnghm.github.io/index.html which has the same conceit -
       | examining programming practices in a different universe.
        
       | adameasterling wrote:
       | I found myself nodding vigorously to Ms. Atkinson's (fictional)
       | responses.
       | 
       | > You fixate on some technical solution and then completely
       | forget what is the context in which you're building it. Good
       | software designers basically treat all problems they face as ill-
       | defined, even if they are fairly specific.
       | 
       | Oh my god, I nearly fell out of my chair. YES.
       | 
       | What we need are tools for software development that are highly
       | flexible, easy to use, and safe. We need to put those tools in
       | the hands of someone like a software designer from this blog
       | post: A domain expert (and/or intuitive listener) who deeply
       | understands the business, understands their customers' needs, and
       | can hook up whatever logic is required themselves.
       | 
       | (And uhh, shameless plug, I'm actually working on a product right
       | now that attempts to realize this dream. We're hiring platform
       | engineers. See my profile for contact info/links.)
        
       | karaterobot wrote:
       | I've been both a professional software developer and a
       | professional software designer, and I always thought the two jobs
       | were more alike than they were different. What is design? Solving
       | a problem the best way, given a desired outcome and a set of
       | constraints. What is engineering? See above. The tool set is the
       | main difference, but the tool set is the least important part of
       | either job.
        
       | walshemj wrote:
       | Ah yes to much time spent on deciding on the correct shade of
       | blue from my sad experience of "web designers"
        
       | karmakaze wrote:
       | > I still feel like this way of thinking can work only up to a
       | certain point. Don't you need to get to a more precise problem
       | definition at a lower, more technical level?
       | 
       | > Not really, no. When you're solving a problem, even as you get
       | to a more technical level, you always keep in mind why you are
       | solving it.
       | 
       | I have mixed feelings about this. On the one hand this pretty
       | much describes many applications built with a lisp. Everything is
       | built to solve the original problem. Every construct made ad-hoc
       | only handling the cases that are relevant, even making up effect
       | partial languages suitable for the subject at hand.
       | 
       | On the other hand, we don't end up with globally shared libraries
       | that have 'completely' solved a particular technical problem
       | space. We actually lose the 'science' of computer science and
       | everyone is an application developer.
       | 
       | Based on the popularity and effectiveness of libraries and
       | ecosystems, I'd say our universe is winning. I do however enjoy
       | quickly making partial implementations that perfectly satisfy an
       | application's needs up and running quickly. Sometimes the
       | complete solution would be unapproachable but the needed one
       | clean and simple.
       | 
       | Perl is an exception--it has a vast ecosystem of partial
       | implementations.
        
         | meheleventyone wrote:
         | > On the other hand, we don't end up with globally shared
         | libraries that have 'completely' solved a particular technical
         | problem space.
         | 
         | IME the more general a library tries to be usually the worse it
         | is to actually use. Opinionated AKA designed libraries that
         | have some specific intention behind them are more immediately
         | usable and it's much more straightforward to see the pitfalls
         | in using them as they tend to typically be intentional.
        
         | wpietri wrote:
         | Huh. I don't see much of a contradiction here. Even the most
         | design-y of software designers isn't going to be picking out
         | artisanally selected sand grains for inventing a new kind of
         | silicon-based processor. At some point you say, "Well, these
         | generic components are good enough, let's use 'em."
         | 
         | That choice of components still requires keeping the purpose
         | and context in mind, of course. But if I want to get anything
         | done for the user, at some point I hit bottom and return my
         | attention to getting something done and out there.
        
         | wrnr wrote:
         | It can go the other way, like I started of creating a POC of a
         | 3D app with three.js and then simplified the code by just
         | creating my own typed array that is send to the gpu.
         | 
         | There are many software designers, they are just not famous
         | because no one would understand what they do.
        
         | MereInterest wrote:
         | While that's a good point, I think that many libraries still
         | have the overall design goal baked into them. These aren't
         | independent libraries that solve an abstract problem somewhere
         | out in the aether, but rather libraries that are intended to
         | fit into specific designs.
         | 
         | Consider a serialization library, for reading and writing
         | objects from memory. This library could aim to have a minimal
         | memory footprint, and may fit into the design of an embedded
         | device. This library could aim to have maximal throughput, and
         | would best fit into the design of a server application. This
         | library might aim for usability by new users, and handle its
         | own memory allocation for the serialized object. But, that
         | would imply serializing the entire object at once, rather than
         | streaming it to disk or to a network socket, so that impacts
         | what designs can use it.
         | 
         | Libraries tend to be implemented such that they fit neatly into
         | some original design. Figure out what that original design is,
         | and that gives you a better sense for how it will fit into the
         | design you're making.
        
       | ncmncm wrote:
       | Visits from a nightmare world.
       | 
       | A world where design flair trumps actually, you know, working,
       | meeting needs.
       | 
       | This is software turned into the movies, or architecture, where
       | the valued work doesn't have to improve anybody's life, and
       | accidents of birth determine rewards. Photographers flock to red
       | carpets.
       | 
       | We already have too much of that here. Fashions dictate web page
       | designs to the near exclusion of the actual purpose of any given
       | site or page. Needed information is artfully concealed behind
       | long downloads and meaningless animation. It is a plague.
        
         | mywittyname wrote:
         | I think people tend to forget about all the things in our world
         | that are invisible, but keep our lives going. Like, does anyone
         | actually care what the frame of their house looks like? Could
         | they pick a fuel injector out of a bin of car parts?
         | 
         | Any attention to the visual appeal of these objects is wasted
         | effort. Some things need to just do a job.
        
           | ncmncm wrote:
           | It is worse than that.
           | 
           | Often the particular choices made for "visual appeal"
           | actively detract from correct function. Designers notoriously
           | insist on sans-serif typefaces, despite their objectively
           | lower legibility. Most phone browsers and messagers make it
           | impossible to select a face where lower-case L and upper-case
           | i can be distinguished, thus: "lIIlllIlII". (Maybe they even
           | differ slightly in your view, but which is which?)
           | 
           | It amounts to contempt for users.
           | 
           | Stewart Brand reported that Architectural Digest readers
           | almost unanimously rejected a suggestion that their annual
           | awards incorporate a measure of users' satisfaction with the
           | building. Contempt for victims of designer malpractice is not
           | just common, it is built into institutions.
        
       ___________________________________________________________________
       (page generated 2021-04-20 23:01 UTC)