I'm currently working with a lot of younger developers and I think most would benefit from reading this type of article. The first bullet point is one I find myself referencing very often.
The tip about revising the on-boarding document regularly is an another very good one. The best team environments I've been a part of had a very detailed and up to date on-boarding/env setup docs.
I had a similar experience once but a little more extreme. On a take home interview test they were asking to build a full backend analytics setup plus a data viz UI. I called the recruiter back and told them an estimate to a problem like this was well beyond the ~4 hours they originally told me. Their response was to say "they were looking for people who would find a way to get it done no matter what". I immediately stopped the interview process without looking back.
Think most companies resist using lower level languages due to their ultimate purpose being to build products that provide value and sell them. They are generally far less concerned with the technical details and conciseness of the implementations. "Good enough" is a very squishy term but for most companies, for better or for worse, that bar is pretty low. There are plenty of industries that focus on lower level langs and use them pretty well but it's not the norm for big corporations who value rapid turn around over all other factors.
Yeah, I'm lucky enough to be able to locally use the prebuilt binaries of seabolt for OS X. I wasn't so lucky with my deployment of it, which is on an alpine container. Definitely not a lot of fun installing the C toolchain & compiling from source but it is doable.
I'd agree with this, I've had good experiences and downright painful ones with performance reviews. I've always found the process outcomes are heavily influenced by the relationship with my manager. I feel like you need a certain comfort level discussing with them or it tends to fall into that "Waste of Time" the author is referencing.
Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.
Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).
There are many reasons to celebrate Stephen Hawking but the one I personally am most impressed by his ability overcome an ALS diagnosis in his college years and go on to live a life of such distinction. It takes some serious courage to soldier on after hearing you may only have two years to live and know that at best you will live a life of slow & debilitating physical deterioration. I'm not sure I could face a such a prospect, so many of the things I enjoy in life require full motor skills and then some. I'd like to think I could adapt and follow such a bold example provided by Stephen Hawking. His story is truly inspiring to me and I hope his story inspires others to do great things.
I read his book, and it seems like his wife should take most of the credit for his survival. Too bad she doesn't seem to get recognition for what she had to go through to help him.
”It is clear that he owed a great deal to his first wife, Jane Wilde, whom he married in 1965 […]. Jane was exceptionally supportive of him in many ways. One of the most important of these may well have been in allowing him to do things for himself to an unusual extent.”
Yeah, I've not delved deeply into the details of his life but that would make sense. Have to imagine she was there providing that day to day support and helped give him purpose.
I generally agree we are products of the environment/circumstance we are born into but it's left to your free-will and choice as to how to best persevere in that environment. I've always viewed talent as the tool that enables you to make the best of the environment you are placed in. Chance/opportunity is not a equally distributed resource but by working hard/efficiently you prepare yourself to make the best of the opportunities you are presented with in life. No one is immune to sheer bad luck but if you did everything you could to set yourself up for success, you shouldn't be derided for it.
I've had a lot of success with paired programming in different team/project environments and really have only done 'mob' experiments. I didn't find there to be a lot of benefit to mobs vs pairing unless the goal was to make sure every team member was highly aware of what was going on in a specific commit/feature-branch.
I definitely think ad-hoc mobbing has it's place and most if not all big design/redesign work the team undertakes should be in a mob form. I'm not sure I could see it being a good practice day to day for most teams/projects though.
The tip about revising the on-boarding document regularly is an another very good one. The best team environments I've been a part of had a very detailed and up to date on-boarding/env setup docs.