Much of the value we add as engineers comes from applying our skills beyond the IDE.  Engineering requires precise attention to detail and prolonged focus.  This combination can be particularly helpful in identifying spoken misunderstandings as they occur, before they become a problem. Having technical conversations is tough.  First, most conversation is casual in nature.  This fosters habits that are counterproductive to discussing technical topics.  Second, speaking precisely about technical topics often requires more time then listeners are willing to give.  The speaker needs to express themselves concisely.  They also need to avoid going off on tangents unnecessarily. Groups tend to explore topics in a breadth-first manner, lightly exploring a number of perspectives.   For a technical conversations to be productive however, it must reach some conclusions by exploring a specific line of thought in depth.  People don't naturally converse in a depth-first manner though.  It has to

  Let's try to produce a framework for comparing job offers. First we should identify what factors make a good offer and add them together.  Then let's disregard everything but the dominant factor, just like we do in Big-O analysis.  At risk of being cynical, let's go ahead and say what most people probably consider the dominant factor, money. We can rationalize this somewhat because many of the disregarded factors correlate closely with money.  Where there's money there's talent, benefits, perks, even social status.  However there may also be politics, competition, even big egos.  Whatever discomfort you may have with the offer, we can collectively call this "culture mismatch." To score an offer based on what we have so far we could say: Offer Score = Comp/Culture Mismatch  We should also make sure to consider the long term possibilities of each position.  A high pay job with little upward mobility will eventually become a mediocre pay job.  Our ability t

  Generally normalization refers to the process of standardizing disparate measurements for the purpose of comparability.  Why do we refer to relational DB design as normalization?  The goal is not to be able to compare data or the system itself to something.  The goal is to represent the data in as concise a manner as possible.  This more closely resembles the process of  orthogonalization from linear algebra. One of the first things you learn in linear algebra is how to make a matrix orthogonal.  This is taught early because it's a necessary step to conduct prior to attempting more complex operations.  Relational database design is essentially the same exercise, with the same purpose.  Eliminate the redundancy in your model to make your life easier once you start carrying out more complex operations.

  K.I.S.S. - Keep It Simple Silly "A Place for Everything and Everything in its place" Eliminate Redundancy aka Orthogonalization In human process design In system, process, and database design In code In communication - Speak Concisely Eliminate Waste/Noise In human process design - toil In system, process, and database design Unused features Levels of indirection In code Unnecessary code Unreachable code In communication Digression & change of topic Pedantry Filler words Minimize Cognitive Load Always be working yourself out of a job Identify and formalize/eliminate repeating manual work Automate/eliminate formalized manual processes with software Design, write, document software so that an uninitiated, junior developer can quickly own it Train team to replace you Foster a Personal Sense of Urgency Engineers are seldom if ever the ones holding the purse strings.  Throughout your career, you'll likely be beholden to someone who isn't technical.  They hire you to