[HN Gopher] All the best engineering advice I stole from non-tec...
___________________________________________________________________
All the best engineering advice I stole from non-technical people
(2019)
Author : techplex
Score : 301 points
Date : 2021-05-30 02:12 UTC (20 hours ago)
(HTM) web link (bellmar.medium.com)
(TXT) w3m dump (bellmar.medium.com)
| n00bdude wrote:
| tl;dr preview -
|
| 1. "People like us make our money in the seams of things"
|
| 2. "Know what people are asking you to be an expert in"
|
| 3. "Before you can make things better, you have to stop making
| them worse"
|
| 4. "To go left, turn right"
|
| 5. "Thinking is also work"
| allurbase wrote:
| Another grandiose self important reflective "memoir" preaching
| All Of The Mistakes I Learned From (tm)
|
| Pretty much falls in line neatly with the All Of My Hard Work
| linkedin posts
| lwhi wrote:
| It actually contains good advice. If it's not relevant to you,
| move on.
| nrvn wrote:
| Kind advice to everyone willing to share their write ups: avoid
| Medium.
|
| I can't read the article because of the signup wall. It is cheap
| and easy to set up a blog on your own custom domain.
| ivanche wrote:
| In situations like these, Bypass Paywalls extension for Firefox
| comes really handy! Especially in combination with uMatrix and
| uBlock Origin.
| CharlesW wrote:
| > _Bypass Paywalls extension for Firefox_
|
| There's a few of these. Can anyone confirm that
| https://addons.mozilla.org/en-US/firefox/addon/bypass-
| paywal... is the "real" one and is safe?
| ivanche wrote:
| Yes, that's the one.
| antman wrote:
| For Android Firefox has disabled almost all addons so the
| same solution is Kiwi browser that can load chrome addons
| (got the solution here on HN)
| tomaskafka wrote:
| > It is cheap and easy to set up a blog on your own custom
| domain.
|
| And no one needs Dropbox, because everyone can easily set up
| some rsync and ftp server
| bambax wrote:
| > _It is cheap and easy to set up a blog on your own custom
| domain_
|
| True. But you can defeat all of Medium's annoying features by
| just disabling JavaScript.
| BossingAround wrote:
| While true, I'd say a lot of people just won't even bother.
| I've seen people refuse to download whole books because they
| needed to put in email.
|
| "You can create a 10-minute email" you say. True, and a lot
| of people do while also a lot of people simply don't want the
| book that much.
| zeta0134 wrote:
| I've found more instances of sites blocking the temporary
| email services (typically forums) than I have situations
| where it worked as a bypass :/
| ajdude wrote:
| I'm kind of like that but in the other direction. I disable
| JavaScript on everything by default, and if I run into a
| website or a blog that won't work without JavaScript, most
| of the time I just give up and leave the site instead of
| enabling JavaScript for that specific domain.
| C-x_C-f wrote:
| This. I've also noticed that websites that don't run
| without JS are either interactive apps (for which it is
| understandable) or sites that want to load JS from so
| many places that I simply can't be bothered figuring out
| which ones to whitelist.
| runawaybottle wrote:
| I think it's a choice to monetize your writings. Medium doesn't
| force you to put your stuff behind a paywall. We need to stop
| blaming Medium and realize the authors wanted to monetize.
| runevault wrote:
| I could be wrong but even if you choose not to join the
| system I think it might still count against views. But you
| can dig into the story settings and get a referrer link that
| does not eat page views.
| zerop wrote:
| One can not associate it to author always. see below
|
| https://news.ycombinator.com/item?id=24314481
|
| I see some of the famous company's tech blogs on medium have
| posts behind paywall. Do you think they would put it behind
| paywall to make money from blog post.. For example -
| https://netflixtechblog.com/empowering-the-visual-effects-
| co...
| Sindaru wrote:
| You can read it in incognito mode
| lwhi wrote:
| Fair enough, but this doesn't have much to do with the article.
|
| I don't understand why it's the top comment.
| snihalani wrote:
| "because they have innate understanding that being observed
| working is more valuable than the results of their work."
|
| so true
| breakintoprog wrote:
| A couple of my favourites include:
|
| "There's no such thing as a stupid question." "Design things for
| the person who's going to maintain it. It may be you."
| kuharich wrote:
| Past comments: https://news.ycombinator.com/item?id=20610839
| zhte415 wrote:
| Not posting on Medium might be missing from the list, but
| consistent with all the points made.
| tomcooks wrote:
| To read this story please login. Yea.
| snovv_crash wrote:
| This feels more like engineering-manager advice, not advice for
| engineers. And, surprise surprise, people are the same even in
| non-technical fields.
|
| I feel it's a similar reason books like Peopleware can still be
| so relevant - we've massively upgraded our computers, but the
| wetware is still the same as it was in the late 80s.
| dilawar wrote:
| Wassup with paywalls on medium these days? Lately, most articles
| are behind paywall for me. I though blogs were for free exchange
| of information!
| jraph wrote:
| Disable JavaScript on medium. Look for my HN comments
| containing "progressive degradation".
| [deleted]
| unixhero wrote:
| Professional investors -> new board -> drive to profit ->
| slowly carve out product, screw the users slowly
| Aeolun wrote:
| How is it that this is literally the cycle. The product is
| great while they're still in the ramp up phase, and then a
| few years later it becomes utter garbage, filled with ads.
| bobbytakeitwith wrote:
| Well, first you run on loans then you attempt monetization,
| and if that fails, then you shutter your windows.
| steve_adams_86 wrote:
| Medium is not really a web log in the traditional sense; it's
| more like a gated content farm.
| speedgoose wrote:
| You can clear your cookies or open the links in private mode,
| but yes it's annoying.
| sum1datduznot wrote:
| in chrome: ctrl + shift + i, ctrl + shift + p, type "clear
| site", enter, f5.
| beny23 wrote:
| > Know what people are asking you to be an expert in
|
| I read this as "leave it to the experts and please realise that
| sometime it's not you" which is something that is sometimes quite
| hard for micromanaging delivery leads or business stakeholders
| when it comes to implementation details. Worst is when there are
| endless progress update meetings about some some irrelevant
| detail that then holds up the whole project.
|
| Similarly it is quite difficult for developers to realise that
| leaving design decisions to user researchers and ux designers is
| a good thing!
| staunch wrote:
| > _" The turning point in my life was the day I realized to run
| great engineering teams I didn't need to be the best engineer in
| the world, I needed to get good at advertising my people and
| their stories up the chain of command. I needed to improve their
| observability so that we can keep bureaucracy at bay by
| maintaining a high level of trust._"
|
| Poof. Another Big Tech middle manager got their wings.
|
| This cynical surrendering is not keeping bureaucracy at bay, at
| all. It's joining the bureaucracy and increasing its size. It is
| the bureaucracy.
|
| At companies that have competent managers up and down the
| hierarchy, it doesn't have to be like this. Good work can be
| judged by good managers, and rewarded, without anyone having to
| play bureaucratic games. There are companies, mostly smaller,
| that work like this.
|
| It seems to reliably fail as companies scale, but for each
| company it might fail at a different point. The longer competent
| management can be maintained, the better chance of the company
| succeeding in a big way.
|
| But all it takes is one good manager hiring a bad manager and the
| whole thing can start to fall apart. Once the company culture
| starts to reward people for playing bureaucratic games more than
| doing good work, it becomes broken and dysfunctional. Diseased.
|
| Everyone quickly realizes that the dynamic has shifted. That good
| work isn't rewarded any better than bad work that is well
| marketed internally.
|
| And so the best people, who have the most confidence and ability,
| go to smaller/better companies that know how to reward the people
| that do the best work. The other people stay and settle in for
| long-term escalating bureaucratic warfare.
|
| And these broken companies are left to fail or ride out the
| momentum generated before they were broken. All the while being
| miserable places to work.
| anticristi wrote:
| > Good work can be judged by good managers, and rewarded,
| without anyone having to play bureaucratic games.
|
| I lost hope this is possible. Even as a non-manager architect,
| I struggle to see good work if it's not made visible.
|
| Fortunately, making good work visible takes little effort from
| the doer: take "before" and "after" screenshots; update the
| docs; if you improved performance, leave some plots behind;
| talk about your work and the benefits it brings.
|
| All in all, if you are a software engineer, stop treating
| yourself as a code monkey and start treating yourself as a
| problem solver. You don't hear plumpers showing their hammer,
| they show the pipe stopped leaking. Same with software, stop
| showing code and start showing their effects.
| staunch wrote:
| A non-manager architect should have some sense. They should
| know all the open problems in their domain and recognize who
| is solving them and how well they're doing it.
|
| But, yeah, the scope is basically limited to each employee's
| direct manager. No one else can reasonably maintain all the
| context and perspective required to judge accurately.
|
| The fundamental requirement is a high level of competence in
| the manager. It usually requires significant self-confidence,
| technical skill, and experience solving similar problems.
| MattGaiser wrote:
| > This cynical surrendering is not keeping bureaucracy at bay,
| at all. It's joining the bureaucracy and increasing its size.
| It is the bureaucracy.
|
| It is keeping it at bay in the context of a team. My company is
| a company with seemingly more paperwork than the government
| (and I used to work in government).
|
| Until a few weeks ago, I saw none of it as an individual
| developer (then we got individual specific paperwork and I
| looked at the required paperwork in the Google drive). A little
| digging turned up exactly why he doesn't have time to write
| code anymore. I would have called my company extremely low in
| bureaucracy before that.
|
| How does that work? He is constantly in meetings with senior
| people. So my manager keeps the bureaucracy at bay from the
| perspective of me by joining it.
| catoc wrote:
| This exactly.
|
| If it works it makes companies fly.
|
| Sadly when said companies grow, the managerial part needs to
| grow, but with that all too often true understanding of the
| technical core is diluted and diluted and diluted
| efxhoy wrote:
| > Security and reliability are more likely to go wrong in the
| seams between components. That means literal integrations, but it
| also means organization seams.
|
| Elon said the best part is no part. Parts between systems,
| interfaces/valves/pumps/APIs/whatever, are often modelled not
| after what makes the most sense for the final system or product
| but often follows the organisational structure of the people
| making the system. So it makes sense that these interface parts
| are often what creates problems.
| ChrisMarshallNY wrote:
| I have always worked with the concept of what I call "trouble
| nodes."
|
| These are basically graph vertexes; places where two (or more)
| things interface.
|
| Every "node" is a potential quality hit. A lot of my
| refactoring involves removing these, using techniques like
| deriving base classes, protocol defaults, or recursion/reuse.
|
| As an example, a couple of days ago, I refactored an SDK I'm
| refining. It has an auth capability that uses an API key
| (bearer token), in a Basic Auth scheme. It does this via a
| common method that generates a URL request, and adds a header.
|
| But servers that run fastCGI don't like auth headers, so I was
| forced to add the option for query arguments to deliver the
| tokens.
|
| So I basically "kludged" it, and added the arguments to the URI
| in all the places the requests were being built. An ugly,
| clumsy, lash-up (I was in a hurry).
|
| This was months ago. I forgot I did that.
|
| As I was reviewing my code a few days ago, I saw this, and was
| quite embarrassed.
|
| Not only was it sloppy, but it was _dangerous_. This was _auth
| stuff_. The worst kind of place to have rotten quality code.
|
| The refactoring was a pretty intense effort, and removed
| _dozens_ of "trouble nodes." It was fundamental stuff, and
| required a lot of testing. If I had taken the time to do it
| right, the first time, it would not have been necessary. I'm
| glad I found it before it became a problem.
|
| And I slept like a baby, that night (waking up frequently,
| cying).
| bjornjajayaja wrote:
| Moral of the story: any public interfaces should be peer
| reviewed by various stakeholders if possible :)
|
| If no one is available, stepping away from ones own work and
| reviewing it with a fresh mind can have a similar affect
| ChrisMarshallNY wrote:
| Absolutely. In this case, I was the only person working on
| it, and reviewing the code long after the fact is what did
| it.
|
| But doing it right the first time would have been better.
| That comes from establishing habit. "We
| are what we repeatedly do. Excellence, then, is not an act,
| but a habit." -Some guy that habitually wore a bedsheet.
| jhncls wrote:
| It's a quote from Will Durant, _The Story of Philosophy:
| The Lives and Opinions of the World 's Greatest
| Philosophers (1926)_
|
| [0] https://en.wikiquote.org/wiki/Aristotle#Misattributed
| ChrisMarshallNY wrote:
| I did not know who did that. Thanks! I knew it was
| misattributed, but was really just a "cliff's notes" of a
| speech ARIS-stot-ly made.
|
| I have never really cared who said it. It's a great
| quote.
| rmellow wrote:
| This is just an instance of Conway's Law: Any
| organization that designs a system (defined broadly) will
| produce a design whose structure is a copy of the
| organization's communication structure. -- Melvin E.
| Conway
| KineticLensman wrote:
| > whose structure is a copy of the organization's
| communication structure
|
| Yes, and if different parts of an organization don't
| communicate, then the systems they develop / procure will
| often be stovepiped.
|
| I have seen this in a UK civil service acquisition
| organisation, that even lacked consistent shared engineering
| guidance for the different teams. They did at least
| approximately follow the same acquisition guidance so there
| were commonalities with how they approached industry and
| managed the bidding process.
| bushbaba wrote:
| "Before you can make things better, you have to stop making them
| worse"
|
| Incredibly great advice. Especially when trying to resolve an
| already broken situation.
| colechristensen wrote:
| Notable failures both personally experienced and famous usually
| involve great amplifications of the issue resulting from
| attempts to fix, often with increasingly urgent and hasty
| actions.
| disgrunt wrote:
| Yes, the adage should be "changes for the better start with
| changes for the worse."
| KineticLensman wrote:
| "The road to hell is paved with good intentions"
| hinkley wrote:
| See also: if you're standing in a hole, stop digging.
| mandeepj wrote:
| Maybe, it's not easy to realize, you are in a hole. Or, at
| least, not during early stage
| marcosdumay wrote:
| Well, of course you can only stop digging after you realize
| you are on a hole.
|
| This phrase is intended for people that once discover they
| are in an always deepening hole panic and do nothing (or
| worse) because they see no way to completely fix the
| situation.
| RHSman2 wrote:
| We are all in a hole.
| Beldur wrote:
| While playing the game of GO, I learned something related:
|
| Don't go on a hunt when your house is on fire
| Terretta wrote:
| Inadvertent best line: _"Hadn't thought I was making decisions
| based on imposture syndrome, but did feel completely out of
| place."_
| below43 wrote:
| A good imposter would not have bad posture.
| valeron102 wrote:
| Do you guys think that managers should have some tech background
| so they could assess any situation and get better decisions. I've
| been involved in a few projects were the lead senior developer
| was having difficult times with the manager. Any thoughts?
| MattGaiser wrote:
| I was on a team where the lead had issues like that
|
| Ran into a lot of situations like this:
|
| https://xkcd.com/1425/
|
| The other common issue was that the non-technicals didn't grasp
| the need for absolutes and specificity. One common issue
| revolved around dates.
|
| So we would get a ticket that "such and such permission should
| expire at a reasonable time on the date specified." Reasonable
| time was not defined and it turned out to be whenever the
| particular thing closed.
|
| They would also forgot to list exceptions to that expiration
| policy, which the people doing it manually would have seen on
| the post-its this system replaced.
| lwhi wrote:
| I think the problem here is often down to non-technical users
| defining the solution, rather than the problem (or aim).
| steverb wrote:
| Yes, I've found that a useful way around this is to go back
| to the non-technical user and ask them why. Why do you want
| to do this? Why do you want to do this in this manner?
|
| That usually either gives the implementor enough
| information to wholeheartedly agree with the proposed
| solution, or to suggest something more appropriate.
| wheelinsupial wrote:
| Where I work, for larger projects, we have business
| analysts or product managers who are supposed to help with
| converting the user request into some sort of
| specification.
|
| If the project is a smaller one, then the developer is
| supposed to be acting in an analyst-developer type role. In
| my fairly limited experience the analyst part tends to take
| a back seat in these smaller projects.
|
| I believe, though people are free to disagree, that it's on
| the people developing the solution to ensure it satisfies
| the users needs. If the user is jumping to a solution, then
| it's up to the team to take a step back and ensure the
| problem has been satisfactorily defined.
|
| Note: I work on internal business apps used in a large
| corporation, and I have never worked on consumer facing
| apps.
| zoltrix303 wrote:
| Good managers should focus on taking the best decisions they
| can with the available information. Sure if they have a tech
| background, some of that information is easier to process if
| technical, but good decisions rely on much more than just what
| is good in the opinion of the tech lead.
|
| If a manager starts analyzing the technical information in
| front of them without the background to do so, they are missing
| the point. They should rely on the opinion of their more
| technical counterparts when the information is technical.
|
| Yet, the opposite is also true, if a technical background
| person becomes manager and doesn't trust their accounting,
| finance, marketing counter part, then they wouldn't be a very
| good manager either.
|
| The above assumes that the manager has a more general role and
| that decisions on technical topics isn't their only job. If
| yes, of course a technical background should be required.
| bendergarcia wrote:
| There's only the minimal amount of knowledge needed. I think a
| manager is no different than a soccer manager. Their role is to
| train the player for the role they're best fit for. A manager
| has to build a team with the right skill sets. And I don't mean
| just technical skill sets. You coach the player during one on
| ones and give feedback, and then during game time, you maybe
| yell strategic advice but the ball is at their feet, they're
| now autonomous unit that needs to work cohesively. A good
| manager gets out of the way and steps in only when necessary.
| The more coaching and autonomy is given the more your players
| develop. The more they develop the more they're capable of
| doing, and the more time the manager can spend thinking about
| higher level ideas and goals. It's a nice feedback cycle.
|
| I do think when the team is more technical than the manager, he
| has to coach the team to communicate the useful information to
| him. It's his job to be able to synthesize information and to
| ask questions that make the team think outside the scope of
| their work, try to find or tease out any gotchas. Lastly a
| manager should be aware of the impacts their teams work will
| have on others and intervene when he thinks something might go
| wrong.
|
| It's always positive when the manager has a very technical
| background or deep knowledge of the tech stack, but they should
| be aware of micro managing.
| WJW wrote:
| I do think that, and (to paraphrase The Mythical Man-Month) I
| also think that it would be great to work on a small and
| focused team with a clear mandate and no legacy stakeholders to
| worry about. So do we all, but those circumstances are not
| usually available.
|
| The interesting parts start to pop up when you need to make
| difficult choices. Good managers with a technical background
| are scarce and therefore not usually available. Sometimes you
| need to make a choice between a bad manager with a technical
| background, a good manager without a technical background and
| no manager at all. Whichever choice is made, it will never
| satisfy everyone.
| RHSman2 wrote:
| A good manager doesn't need to be technical as they are a
| managing people. That is the hard part. Not tech.
| WJW wrote:
| If that was truly the case, then why do so many engineers
| complain about having a non-technical manager? Thinking
| that a manager does not need even a little bit of domain
| knowledge is something managers tell themselves to feel
| good about themselves, but it is not actually true.
|
| Both the people part _AND_ the technical parts are the hard
| parts of technical management.
| dopidopHN wrote:
| Thanks for some sanity.
|
| Of course some domain knowledge is needed.
|
| My anecdotal experience with manager is either : they are
| useless and will rubber stamps things. Or they are
| actually involved, then, you want someone that has a
| vague idea of the process of doing the work. I vastly
| prefer someone who has produced code at some point. It's
| fine if it was 10 years ago the last time it happen.
| booleandilemma wrote:
| If you're a manager and not technical you're not going to
| understand what your people are doing, you're only going to
| understand what they tell you.
|
| Also, you're going to be manipulated and hoodwinked by the
| managers around you who _are_ technical.
|
| Lastly, the engineers you're managing are going to laugh at
| you behind your back.
|
| I've seen all of this happen before.
| vehementi wrote:
| Hmm, am I writing posts in my sleep?
| username90 wrote:
| If your manager has no power to decide what you work on,
| who gets promoted, what deadlines you should have, who is
| to blame when things go wrong, who to fire etc, then sure
| he doesn't need to be technical. Otherwise he will just
| promote and listen to the popular guys and fire the
| unpopular ones.
| codingdave wrote:
| It depends on their leadership style. Micromanagers needs tech
| backgrounds. Hands-off delegators need communication of goals,
| and to trust their team.
| neonate wrote:
| https://archive.is/3XAhy
___________________________________________________________________
(page generated 2021-05-30 23:01 UTC)