Another grandiose self important reflective “memoir” preaching All Of The Mistakes I Learned From ™ Pretty much falls in line neatly with the All Of My Hard Work linkedin posts
It actually contains good advice. If it's not relevant to you, move on.
All the best engineering advice I stole from non-technical people (2019)
41–50 of 91 posts
Re: All the best engineering advice I stole from non-technical people (2019)
#42Kind 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.
> 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
Re: All the best engineering advice I stole from non-technical people (2019)
#43> 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 syst…
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 capabilit…
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
Re: All the best engineering advice I stole from non-technical people (2019)
#44Earlier quoted context omitted.
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 capabilit…
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
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.Re: All the best engineering advice I stole from non-technical people (2019)
#45Earlier quoted context omitted.
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 a…
A good manager doesn’t need to be technical as they are a managing people. That is the hard part. Not tech.
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.
Re: All the best engineering advice I stole from non-technical people (2019)
#46Earlier quoted context omitted.
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 a…
A good manager doesn’t need to be technical as they are a managing people. That is the hard part. Not tech.
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.
Re: All the best engineering advice I stole from non-technical people (2019)
#47Kind 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.
You can read it in incognito mode
Re: All the best engineering advice I stole from non-technical people (2019)
#48Earlier quoted context omitted.
A good manager doesn’t need to be technical as they are a managing people. That is the hard part. Not tech.
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.
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.
Re: All the best engineering advice I stole from non-technical people (2019)
#49Kind 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.
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.
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...
Re: All the best engineering advice I stole from non-technical people (2019)
#50> 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!