In addition, same set of questions can also be asked to people who've recently left the organisation.
I'd use the following criteria to filter ex employees:
- Reliable 1st/2nd level connections
- Folks who have shown stability in the past (generally stick to jobs for > 2 years)
Obviously, they'd come with biases. But, talking 2-3 people should also help reliably gather broad culture patterns.
Should avoid listening to evidently disgruntled folks.
> DON'T BE AFRAID TO DISMANTLE THE WRONG ABSTRACTION
Couldn't agree more with the statement, though I don't completely agree with the author's suggestion to copy paste. Duplicating code _is debt_. It may help us go faster now, but it'll almost inevitably come back to bite. It is manageable if 1/2 people do it 1/2 times - definitely not manageable if 5/6 people do it 5/6 times.
I believe the general hesitation of not touching a piece of code (or, getting by with that optional param) is due to the fear of fucking things up. Having your code test covered gives an amazing amount of confidence to rip apart old abstractions to yield newer ones that serve the purpose of the _current code_. To me, this route is more preferable to duplicating code.
Even with the best of intentions, Hacking an abstraction with that one optional parameter is inevitable. Tests help in our ability to repay that debt faster - on time & in full.
Basically they make all abstractions a lot cheaper - easier to write and easier to throw away. Thereby solving the problem of having a 'wrong abstraction' too early.
It is almost always better to copy/paste a function to accommodate "that one optional parameter" that breaks the original abstraction, than to add the parameter to the function signature. The "cost" of a broken/leaky abstraction is at least an order of magnitude higher than that of duplicated code.
While I completely agree with your _sentiments_ I think there is a conflation between choosing _the right tool_ for the job vs using 'too many things'.
I shun the unnecessary - completely with you on that.
But I'd prefer gaining relative mastery over _1 decent tool_ in each of the areas that you pointed out so that I have enough tools in my toolkit which prevent me from using the wrong tool for the wrong job. For example, I'd hate to use shell scripts to do something that ansible does really well.
A modern solution, fortunately or unfortunately, is built up of multiple smaller tool sets as you pointed out - and, if used correctly, each enhance productivity tremendously. Writing a frontend app (something that I've only recently started doing since I'm on my own) is immensely more productive if working with something like react rather than with a relatively old framework based on the jvm.
What I'm trying to say is - tech we use is ultimately a tool - we should optimise for productivity. In that case, Boring Technology helps being more productive since we know a lot more about it which makes it easier for us to bend it to our will as well as debug/diagnose the unknowns.
But it also doesn't mean we continue to use `grep` when silversearcher/ripgrep is out there in the world :)
That's the lens that I look with when I come across new tools/technologies (regardless of how long they've been around) - do they have the potential to be net-productivity enhancers over a long-ish period of time && by how much (0.5x? 5x?).
Thank you for starting such an interesting thread.
Going through all the comments a few days after the question was asked is very rewarding ! So many books marked as 'to read' :)
My contribution:
If you're not familiar with Quantum Physics, do check out 'Through Two doors at once'. There were numerous instances while reading the book that I had to just put it down and think deeply - mostly philosophical thoughts around what we are and how magical nature is. The subject matter is very very approachable - even to someone like me who hasn't read a physics book in like a decade.
Thank you for this - and the references to how you came across the concept.
I was personally only recently introduced to anki [1] & [2]
However, I tried it out but I couldn't end up using it to 'remember books' or broader concepts that the books convey indirectly. I've started summarising books and using a manual form of spaced repetition to remember them better.
Do you have any advice on organising such knowledge better?
I just take handwritten notes, then convert them into carefully designed and tagged cards in Anki. Even if I forget something, searching my Anki deck will usually not just tell me the information, but what book it came from, and often which page. I'm pretty diligent about careful note collation. I've definitely gotten better since I read "The Organized Mind", a book which was so enlightening for my persona that I built more than 1000 cards to remember as many of its concepts as I could.
Regardless, I'm reading my previous comment and should admit that I'm quite intense about efficiency in learning. Less so about money. I've spent a lot of time tutoring, making this an important subject to me and I get.... emotional. I apologize if my original comment seems rude. It certainly feels that way to me.
You mentioned "if one person on a team of 10 engineers spends 3 whole days shaving off even 30 seconds on a task done by everyone only 5 times a day, we would have gotten a complete return on investment over a period of just 6 months".
How did you get 6 months? can you shed some light on the calculation? Thanks!
("Does xkcd even need attribution?" Sir? https://xkcd.com/1053/ would you forego the delight of being the one who introduced somebody to XKCD? (^_^) <3 )
Thanks for the feedback. It does have a short write up on things to do. I have a lot more opinions on that, but was trying to balance out the overall length of the post.
Will try having one out just on the dev environment :)
Looking at it again I didn’t realize the following sections were actually part of that header because the headers were the same size and style. I thought it was only that one paragraph about Jedi. That was my fault.
This is quite the representative case between Infra teams (or PaaS or SRE - based on where you're located) and application teams.
Being part of the platform team, I've been in the exact same situation before at an ex employer. We assumed that _infra problems_ were _everyone's problems_ and how can anyone who cares about their application _not_ adopt to the latest-and-greatest-platform (or tool) we released.
A lot of time was spent on figuring out the 'best approach' to getting everyone onboard quickly - we tried the carrot and the stick. We failed miserably at both.
The trouble is, as someone else mentioned here - we didn't really go and _talk to the customer_. Internal customers are customers too - and 'product' thinking should be equally applied to all internal platforms. The general rule applies - talk to the customer and understand what they're going through. They have their own sets of problems and priorities.
(a) Is the latest way actually _saving them a lot of time_
(b) Can we take another 2 weeks and make it even easier for them to come on board?
(c) If they're really busy and/or lack the expertise, can we carve out some time to give enough training sessions?
Yet, this never happens and we invariably end up blaming the application teams for _not doing this seemingly simple_ change. It may seem downright stupid from the platform engineer's PoV, but we are partly to blame.
This also leads me to think that the cloud wars will be won by the <cloud-provider> that does this job better - of understanding the customer needs on a day to day basis and building platforms for them.
Whenever something isn't installable through the package manager I check if it's feasible to install in `$HOME`. Most of the times it is, therefore rsync'ing home directories works surprisingly well. (Especially on work computers which I keep much more tidy than my non-work computers)
In addition, same set of questions can also be asked to people who've recently left the organisation.
I'd use the following criteria to filter ex employees:
- Reliable 1st/2nd level connections
- Folks who have shown stability in the past (generally stick to jobs for > 2 years)
Obviously, they'd come with biases. But, talking 2-3 people should also help reliably gather broad culture patterns. Should avoid listening to evidently disgruntled folks.