itsmejeff

W1nning - Tim Grover

Never Split the Difference - Chriss Voss

Three Laws of Performance - Steve Zaffron

Peak - Anders Ericsson

All of these books fall into the category of rounding out my world view. I’m an engineer, and spent nearly 100% of 10-12 years of my life (school plus early career) focused solely on engineering topics. These books have made me drastically more effective at achieving personal and professional goals, especially ones that require cooperation of other people.

My process is to dig in and really try to apply the knowledge in some place where it is required to solve the problem.

This has never failed me, but it’s hard, because it’s WORK. You can’t just sit and consume material (though consuming material is important). My typical strategy for consumption of material is to do such when I hit a road block in the application of my knowledge.

A few concrete examples to get the idea:

Want to learn about how cars work? Don’t take your car to a mechanic, force yourself to fix it.

Want to learn about electronics? Build an electronics project.

Want to learn about machine learning? Build an actual ML powered software application.

Want to learn about math? Use it to solve a real problem (physics/engineering has some of the most concrete representations of applied math from algebra to through differential equations, etc)

More difficult subjects will take more “projects” in order for you to gain in-depth knowledge. However, nothing beats experience at applying the knowledge in order to achieve true mastery.

Where some folks get hung up is they think they need to pass some knowledge threshold before they begin to try to apply it. I think this is false, for any application where a lack of knowledge is not actually dangerous. The sooner you try to apply what you know, the sooner you will master the subject.

I really like thought exercises like this, but find it troublesome when authors (like this one) do not offer alternatives that address the weakness of the common approach, they just just point the weaknesses out and metaphorically “shrug”.

Left with this, people will still revert to the status quo because they’ve been offered no true alternative that provides more value.

This may be a bit of a paradigm shift on the original question, but I’ve found that arranging my software and project in such a way that “cognitive overhead” is minimized will make startup cost extremely low.

If the code is very simple to reason about at a high level, you won’t need to remember many details. If your dev environment is stateless such that simply “opening the project” (for me, cd-ing into the project directory in my terminal) will automatically set up everything you need to start iteratively developing, you won’t have to focus mental energy on project setup.

This leaves you free to really only worry about the exact thing you were doing.

I’ve been pondering this a lot lately, as an engineering leader.

Masters in my organization have an extremely high ratio of value shipped to hours worked.

This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such that the cost of adding more value to the system remains constant as the system grows in complexity.

I got bored with engineering because it became easy. The patterns always repeated, and I knew that the only thing standing between me and my desired outcome was a fully understood path of actions.

I don’t believe you have to reach this level across a wide domain, but you should be able to achieve it within some reasonably narrow technical scope. If you don’t, you will not be able to lead a technical team effectively. When you are in leadership, you may not always be on the hook for delivering, but you can win major support from your team if you are capable of diving in and doing something technically impressive from time to time. In addition, you will need to be able to teach engineers and guide technical implementation, which requires the ability to communicate clearly about deeply technical topics. I find that the less I know about a construct (think Law of Demeter, etc.) the less I’m able to communicate it to others or build solid arguments for or against it.

I think you must dig in and obsess about becoming great at engineering. My passion for this role is because of its meta nature. I love engineering and have built strong opinions about it over my career, and now I want to engineer a team of engineers who can see things similarly, and ultimately do greater things collectively. This wouldn’t be possible if I didn’t take the time to be a great engineer first.

No, I already have two MS degrees (1 in Mechanical Engineering, 1 in CS) — I’m not interested in more school.

Maybe that will change in the future.

Truthfully — the biggest thing has been leaning into my gut more as opposed to trying to reason through everything thoroughly. The decisions are many and the time is short. Kahneman’s “Thinking Fast and Slow” is a great read, and when working in engineering management, the conclusion to be drawn from it is that your gut (aka system 1) is actually really good at summing all of your past experience and telling you what you should do. There is definitely more in the domain of human psychology that I have studied as well.

In addition, I’ve been forced to continue to hone my technical skills, but more in the domain of “why” instead of “how”. I was able to be an effective engineer by mastering the “how” (which of course required some non-zero knowledge of “why”). However, the types of minds that exist in engineering (or at least the types I want on my team), are not satisfied with a boss telling them “how” to do something. The reasoning must be sound. Engineers want to see the work. If you can’t provide compelling arguments for why a new policy or decision exists, then you quickly lose credibility.

When I got bored with software engineering, I decided to invest in developing leadership skills and to try to build teams.

Many people (myself included) are motivated by the impact their career can have. The impact of a great leader is exponentially larger than that of a direct contributor (based on the number people they can typically influence, and the amount of resources at their disposal to pursue “bigger” ideas). A great engineer who is also a great leader will garner more respect from their team, and will be more effective than a great leader who was not a great engineer.

I’m currently a Director of Engineering, and have a goal of becoming a CEO. This is something I never remotely considered, and even scoffed at early in my career.

The transition has been difficult and exciting. I considered myself to be an excellent engineer, so transitioning to a role where the new challenge is how to convince other brilliant (but possibly less honed) technical minds to do things has been extremely fulfilling. It forces me to think harder about my habits as an engineer and why they are important and how I can communicate that — it also forces me to have humility and admit that some of my habits may not have been as good as some things other folks are doing. It’s been extremely fulfilling, and I’m much more excited about my future than I was during the last few years I was a software engineer.

The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don’t complain about business constraints and they put out stellar work.

“business people” most often do understand what makes the money flow through their company (and into engineers’ bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don’t understand the technical details of an engineer’s work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It’s not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.

(fwiw I’m a director-level engineer so I’m technical but bordering on being a “business person”)

If it was important to your well-being you would have already addressed it. Delete it all and start fresh. Or just stop altogether.

“All these super smart people who came before me spent more collective time than my entire life, but the solution they arrived at is wrong “

This Freakonomics episode about what’s missing from the standard math curriculum is really good http://freakonomics.com/podcast/math-curriculum/

He calls it a "relative operating characteristic curve", then links to a Wikipedia article for the properly named "receiver operating characteristic curve". Maybe I'm wrong but I've never heard the former term used.

Jupyter Lab may be more like what you're after: http://jupyterlab.readthedocs.io/en/latest/user/interface.ht...

It's almost trivial for computer vision to recognize a child -- we already have backup safety cameras to protect children (among other things), why not a backseat cam?

This article climbs the HN ranks once every few months... I'm a "real" engineer who chose to make my career in software. There are obviously things that this author does not know about software engineering and there are things that software engineers don't know about "traditional" engineering. Both have their strengths and weaknesses. Everybody chill out

The Nash equilibrium for an unlimited vacation policy is no vacation for anyone.

https://www.amazon.com/Algorithms-Live-Computer-Science-Deci...

I use http://marxi.co, which is an excellent markdown to Evernote tool.

This has gotten me through many college courses. Working on my second MS right now.