[HN Gopher] Thinking about software engineering
___________________________________________________________________
Thinking about software engineering
Author : funkisjazz
Score : 61 points
Date : 2021-01-29 12:42 UTC (10 hours ago)
(HTM) web link (nintil.com)
(TXT) w3m dump (nintil.com)
| funkisjazz wrote:
| Hopefully the article is enjoyable to those that haven't read his
| blog, I stumbled upon it because I'm a fan on nintil in general,
| but I think it's interesting even if you aren't familiar with his
| other writings.
| raw_code69 wrote:
| I second this , this blog is gold.
| simpixelated wrote:
| Thank's for sharing! I hadn't heard of him until now. Love the
| suggestions for how to have better meetings especially.
| MaxBarraclough wrote:
| > You can write more or less tests, you can be more or less sure
| that something you just wrote is actually correct.
|
| At the risk of taking things too literally: that's quite an
| exaggeration. Even the most cautiously written code (short of
| formal verification) often turns out have serious bugs.
|
| _Linus 's law_ (curiously apparently written by ESR) famously
| states that _given enough eyeballs, all bugs are shallow_. This
| implies that the typical initial value of 2 eyeballs is
| inadequate, but even Linus 's law doesn't seem to go far enough.
| Sneaky bugs can hide for years in mature codebases.
|
| > If you take say SOLID which sounds kind of reasonable, the
| Single Responsibility Principle in an OCD way can only be met by
| unary functions. Everything else must be doing more than "one
| thing".
|
| I don't see where this is coming from. Multiplication is an
| operation over two operands but it's clearly 'doing one thing',
| to the extent that this is even meaningful.
| cccc4all wrote:
| There are many misunderstandings in Software Engineering. The
| first main misunderstanding is that Software Engineering is about
| writing code. I would argue that is the main misunderstanding.
|
| In reality, software engineering is about solving problems,
| business problems, process problems, machine problems, etc. using
| code in software as a tool.
|
| The 80/20 rule applies here. 80% of time is spent analyzing and
| developing solutions, 20% of time is spent writing code and
| developing software.
|
| Too many people focus on the code part, when they should be
| focusing on problem solving part.
| mcavoybn wrote:
| >Absent tooling to detect dead ode I'm not sure if this is a pun
| that is over my head or a typo.
|
| Thanks for the article. I think the most difficult issue to solve
| is the meetings one, especially now that so much work is being
| done remotely. It's easy to have inconclusive meetings in
| engineering because you can just handwave your way through a
| project that drags on for too long and any non-technical
| stakeholders will have no choice but to put up with it. Also,
| engineering is complex and it's easy to over-commit and end up
| with really tough problems to solve.
|
| One thing I'd like to add is that a "meeting" should minimize the
| number of active participants. If a "meeting" has more than 4
| people it should be considered a presentation. It's a waste of to
| be in a meeting and trying to follow a conversation that you
| aren't involved in. If there is information in that conversation
| that others need to hear, it should be documented in some way.
| the_arun wrote:
| Thing is execution of Software Engineering is highly opinionated.
| People with diverse cultures have different needs & skills. It is
| very difficult to write one doc that doesn't raise questions or
| meetings. I guess we can minimize them by holistically
| understanding the use of the doc we're creating.
| macintux wrote:
| > Lack of ownership is the root of all evil
|
| This is something I battle at every job. Every meeting should
| include as a documented outcome: who owns this gap we just
| identified?
| simpixelated wrote:
| One point that I disagree with is "Every question asked in an
| internal Slack is a policy failure. It means the existing
| information systems failed to deliver an answer, and the user
| falls back to manually asking the hive mind's tacit knowledge." I
| find it's usually a failure of the doc search mechanism. It's
| much faster to ask humans a vague question than try to form the
| right search query for the internal doc system, which is usually
| much much worse than Google.
|
| This can be solved by making docs public, but also by having
| people respond with a link to the docs. So Slack can still be a
| good interface to Q&A, as long as a single answer is documented.
| jcelerier wrote:
| honestly, it also sounds like author's dream place to work is a
| Brazil-like bureaucracy. ugh.
| MaxBarraclough wrote:
| That wasn't my take. Good documentation doesn't equate
| bureaucracy.
|
| 20 years ago, Spolsky wrote a blog post about how good
| documentation need not be unreadably dry and soulless. [0]
| From which:
|
| > _Rule 1: Be Funny_
|
| > _Yep, rule number one in tricking people into reading your
| spec is to make the experience enjoyable._
|
| [...]
|
| > _if you work in a company where people will respect you
| less because your specs are breezy, funny, and enjoyable to
| read, then go find another company to work for, because life
| is just too damn short to spend your daylight hours in such a
| stern and miserable place._
|
| I'm not sure I'd go quite that far - it seems a bit much to
| leave an otherwise agreeable position just because they
| insist on humourless documentation - but I think he makes
| some important points.
|
| [0] https://www.joelonsoftware.com/2000/10/15/painless-
| functiona...
| hirple wrote:
| Really interested in the 'custom pandas typechecker'. Are there
| any more details anywhere, or has anyone else tried writing
| something similar?
| musingsole wrote:
| https://pandera.readthedocs.io/en/stable/ <- Pandera is a
| fantastic module for applying schemas and validating Pandas
| dataframes.
| dfilppi wrote:
| No, meetings are usually not for thinking. They are for
| delivering status to an authority figure while wasting everyone
| else's time for the convenience of said authority figure.
| yagodragon wrote:
| What would be the best programming language matching his
| criteria(flexible, concise, static types, DSLs)?
| donut2d wrote:
| OCaml seems like it hits all of those well.
| namelosw wrote:
| If those are the only criteria, my take would be Haskell.
| MaxBarraclough wrote:
| Ada makes a real effort toward _if it compiles it works_ ,
| which is an exaggeration of course but Ada is much closer to
| that ideal than is C. More recently we have Rust, but Ada is
| too often overlooked.
|
| I'm not quite sure what to make of those criteria. If you want
| a platform for writing DSLs, I believe Racket Lisp is
| impressively flexible, but it's a somewhat exotic language.
|
| For flexibility and conciseness, functional languages are the
| obvious place to look.
| systems wrote:
| most typed functional languages seem to fit: ocaml, f#,
| purescript, haskell
___________________________________________________________________
(page generated 2021-01-29 23:02 UTC)