Author: Neil
Mentors
Musk
Fear
Bugs
Security
Politics
Intuition and Ergonomics
Agile
Dealing with a Diva Developer
Cyberpunk 2077
Dave Whipple’s Wisdom
Growth Mindsets
Volkswagen vs. Tesla
Ethics
The Architect’s Dilemma
ScrumMaster.games
Laziness and Incompetence
Employee Happiness
Breaking Up Facebook
Architecture’s Relationship to Business Outcomes
PSF: Previsualize, Sleep, Flow
Improving Scrum
Career Advice
Is It Worth Learning to Be a Software Developer in 2020?
Haters
My Perfect Business
CoffeeScript/Battojutsu
Brainstorming/Stoicism
WiT
WordPress/Code Pledge
Planting Seeds
Code Consistency
Atlanta

Non-Technical Development Managers Are Like Head-Chefs Who Can’t See, Taste, or Smell
I have made no secret of the fact that that I find non-technical managers useless in the delivery of software, but today while recording a podcast, I realize they have another fatal flaw: they can’t evaluate the performance of their team.
Read More »12 Types
Timelines
Generation Gaps
Capitalism
Leadership
Management
Rewrites
Breaks
Architecture
My Goal
Contact Tracing
Intentional Design
Gaslighting
DnI
10x
WFH
Remote and Junior
Coding Tests
Imposter Syndrome
Organizational Change
Agile’s Future
Arrogance
Quitting
Collaboration
Collective Ownership
Hackathons

Email Is the Worst Form of Internal Communication
Email is the worst form of internal communication in common usage today. The only redeeming characteristic of email is to create proof that at some point in time, you tried to inform someone of something. In this way, it is very similar to its direct ancestor: paper mail delivered by the postal service, and it is just as obsolete. Unfortunately, as remote work has become an immediate necessity for millions of people worldwide, email has become a primary form of communication.
Read More »
Conference Call Sins: By Example
The following audio clips are examples of the most common mistakes people make during conference calls.
Read More »
What are Soft Skills?
Hard Skills are necessary to get a job, but Soft Skills are required to have a successful career.
Read More »
Agile History: Kent Beck vs. Alan Cooper
It can be argued that Scrum is the compromise Beck and Cooper had such trouble reaching in the following interview. As the original website where this was posted no longer exists, I copied the contents from the Internet Archives and reformatted it to improve the reading experience.
Read More »
Defending “Never raise a problem without a solution”
I want to offer a soft rebuttal to the article The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions. By “soft” I mean to say that I do not disagree with the thesis, only some of the implied assertions. Bear in mind that critiquing “Implied assertions” can be deeply unfair in a work that is intended to be taken literally.
Read More »
The Danger of ‘The Dark Sage’
JP Ventura left an intriguing comment on The Sage that I’d like to explore:
Considering each coin has two sides, what would be the dark side (i.e., opposite) of the Sage?
What I find interesting about this question is the fact that I had not given much thought to the “dark side” of the 12 highly effective developers. The Sage, in particular, can have several dark manifestations as ostensibly, they are supposed to be a benevolent master whose primary interest is helping the members of their team grow. If we look at someone who is pretending to act in a way that could be confused with The Sage but is, in fact, the opposite, we get something like this:
Read More »
How to not get promoted
So you’re a high performer who likes their current position, but your boss keeps threatening to promote you so you can take on more responsibility. Here are some surefire ways to get them off your back.
Read More »
126 Soft Skills Every Developer Needs
The following are 126 soft skill topics divided into 14 categories.
Read More »
The relationship between determining technical feasibility and productivity
This is an answer to a question asked by Ashvini Chaudhari in the “Agile and Lean Software Development” LinkedIn group:
Read More »Dear All , I m pursuing my PhD in Agile Software Engineering. I have a question regarding spike solution ” If we add spike in project development will it have effect on team velocity? and if yes what could be the parameters ? All the responses will be consider as a general opinion in my PhD thesis.

I pity Tim Cook
It’s clear the Job’s deathbed playbook has long since been used up. The Apple devices are getting worse and worse year over year, but Tim Cook has managed to drive shareholder value despite that. Apple is the most valuable company in the world – no one can take that away from Tim Cook; but Apple has fallen from grace, and as captain of the ship Tim Cook bears all the blame.
Read More »
CoffeeScript is my Bullwhip

Define your problem before picking a solution
Our industry revels in coming up with solutions, but is quite poor at defining problems. This has resulted in an vast constellation of technological solutions, but with the majority of investment capital being centered around a small handful of banal consumer problems (Hailing Rides, Shopping Convenience, Entertainment, etc.) If we are to solve problems that are worth solving, we’re going to need to get better at defining our problems before we pick solutions.
Read More »
“Artificial Intelligence” is deeply disappointing, and so are we
The term “Artificial Intelligence” transitioned from Science Fiction to Product Marketing with very little time in-between to consider what exactly qualifies as “AI”. While tackling this definition has been done ad nauseam for hundreds of years, I believe that the modern definition of “AI” and those from Science Fiction are worlds apart. This is my attempt to bridge that gap.
Read More »
Why management will not change their open office layouts
The first study of how open offices affect communication has been conducted, and the results should not be that surprising. Open offices negatively impact productivity, and we’ve known that for a very long time.
Read More »
My response to “As a team lead how to handle project going off the rails?”
This is my response to a question posted on HackerNews.
Read More »
Let Loose your Lions
Enterprises complain about their inability to innovate at a pace that even approaches that of startups, and yet puts into place every system imaginable to prevent a team of Lions from forming and executing.
Read More »
How important is code quality vs. getting things done?
Anyone who lacks the knowledge of how to build quality software, as well as the wisdom to know when code is good enough to ship, does not have the experiential background to have a valuable opinion on the code quality vs. getting things done debate.
Read More »
Are we working or playing?
Recently I’ve been talking to companies that want me to improve staff productivity. The opening conversation tends to be about the same: they pitch me on their company and what a “great place to work” it is. They brag about how smart the people are, how much fun everyone has, and how it’s more like a family that a bunch of co-workers. They describe all the perks like massages, video games, beer-on-tap, coffee bars, and how much everyone loves them. “Sounds like you have it all together,” I say after hearing all of this. “Well,” they reply, “I just wish we could get a bit more out of them.”
Read More »
My Response to “How to *never* complete anything”
The following is my response to Ewan Valentine’s blog post “How to never complete anything” that I discovered on Hacker News. Once again, I ask for people’s indulgence for posting a reply on my own blog rather than in the Hacker News comments. I find writing on my own blog a bit easier than wading into the surf that is the sea of many perspectives.
I didn’t think of responding until I read your very last paragraph, at which point I felt compelled. I understand what you are feeling because of my similar experiences, and so I will give you the advice (albeit, unsolicited) that I would have wanted someone to have given me when I was going through what you are going through:
- “I’m challenging myself now to do the opposite” – That would imply absolutely everything you were doing before was wrong, and it was not.
- “keep things extremely simple” – The quest for “simple” is a life-long pursuit. What one person may see as complex another can see as simple, and vice-versa. The most extreme case of simple is to do nothing at all, so do don’t quest for extreme simplicity. Instead, quest for elegant minimalism, and know that you’ll only know it when you see it.
- “Unglamorous” – This is important, and I’m glad you realized this. Important work is rarely (if ever) glamorous while it is being done. The glamour comes much later if at all.
- “Dumb” – See comment about elegant minimalism. “Dumb” implies a stupid solution, which is not going to help anyone long-term.
- “Sometimes ugly” – Replace “ugly” with “effective and efficient” and you’re onto something. There are times when you need an effective solution now, as efficiently as you can get it done. The result a cynical critic might call “ugly” but I would characterize as “necessary”.
- “But done” – What is “done” in software? What software beyond the most foundational of algorithms is ever truly done? Software is liquid to the constraints put upon it, and the only constant constraint is that things will change over time.
- “No more big re-writes because there’s some hot new JS library” – Most definitely not for that reason alone, but don’t shy away from a new solution to a long-standing problem. There are times when you have struggled with a problem that has caused you an enormous amount of headaches, and a new framework comes along that neatly solves all of them. The challenge is evaluating cost/benefit, which is something that only comes with experience.
- “No more microservices for the sakes of it, no more overly ambitious build pipe-lines.” – “for the sake of it” is perfectly fine if your objective is to learn. You are still relatively early in your career, if you consider when you might retire. You are still learning (as we all should always be), and it’s important to thrash around a bit as you understand the nature of non-trivial systems. Often, our learning is done in the context of attempting to get things done, and we are hard on ourselves for not achieving the original goal. When I feel this way, I remember the Thomas Edison quote of “I have not failed. I’ve just found 10,000 ways that won’t work.” Often failing to achieve something is more instructive than achieving it.
- “NO MORE TRYING TO REWRITE THINGS IN HASKELL.”– Haskell falls into the category of tools worth learning, as it opens your mind to new ways of looking at problems. It is obvious you are thirsty for knowledge and experience, but that is running into conflict with your strong desire to complete things. At any given point in time, you are going to have to decide what is more important to you: getting something done or learning something new. Both are important, but don’t put undue pressure on yourself by trying to do both at exactly the same time.
- “JUST. GET. SHIT. DONE.” – Well, you are – during your day job and freelancing. You absolutely know how to get things done. You do not have a general productivity or discipline problem as would be evidenced by your inability to accomplish anything at all in any aspect of your life. If you tell me, “I can’t get shit done” I will point to all of the tasks you have gotten done. The issue is you’re not getting done the things that are most important for you to get to done. You are not satisfied with your own progress. It is you that have created the fantasy that you cannot get things done, and you are letting it tear you up. I won’t say something trite such as, “You’re being too hard on yourself”, instead I will ask you to ponder, “Why am I not satisfied with my own progress on the things I am progressing on?”
Beyond this, here are a few additional things I would like for you to consider:
First, I believe your tea-cup is full. You have a lot swirling around in your head, and I don’t know if you have the space necessary for new, productive work to fill in. I would wager you know far more about emerging technologies than I do, as I suspect you have a knowledge addiction. We all have finite capacities for knowledge due to the limitations of our brain, but the web is a limitless stream of data from which we must carefully select what knowledge we should internalize. The “Fear Of Missing Out” can have us figuratively glued to the screen, never wanting to be that person blindsided by our peers when they know something we do not. That fear can blind us to the negative effects knowledge obsession has on our mind.
Speaking of peers, I worry that you are subject to peer pressure. Positive peer pressure can be just that, but you may be experiencing the darker side of peer pressure, and not be fully aware of it. Should every software developer have side projects? It depends on where that software developer is in their professional and personal lives. Single with no responsibilities other than your day job? Absolutely. Married with a newborn baby? Probably not. Married but worried about your financial future? Probably. Parallel to this progression is your level of expertise in delivering software. By “expertise” I don’t mean only knowledge or proficiency, but experience. How experienced are you in delivering software? I would say that I only knew how to deliver software under optimal circumstances about 7 years into my career (for many of the same reasons you are citing), and it wasn’t until about 15 years into my career that I could do it under adverse circumstances.
Speaking of circumstances under which you are working, are you optimizing your circumstances to maximize your productivity and therefore maximizing your chances of accomplishing your goals? When I felt that the time was right in my professional and personal life to build my own application, I quit my job and spent a year working in near-isolation (outside of my wife and visits from a few close friends). The book “Deep Work” explains this phenomena quite well. I am introverted (a Myers-Briggs INTP), a bottom-up learner (essentially a “slow” learner), am very easily distracted, and it can take me quite a while (hours and even days) to get into the highly-productive state referred to as “the zone”. I know this about myself, and as a result I knew that if I was going to build my own app, I needed to optimize my circumstances for the way that I work. My home office is relatively spartan and minimalistic, and the standing instructions to my wife is that if the office door is closed, only open it if the house is on fire and you have reason to believe I would not survive it. This is what I know I need to get things done.
Finally, I think it’s time for you to have a vacation – a real vacation that is restorative to your mind. Among other things, it should include exercise, nature, solitude, and sleep – lots and lots of sleep. How long you need will depend on how much you need to process. Sometimes a day-hike at a local park is enough. Sometimes, a week in the Caribbean walking the coast and napping on the beach is necessary. One of the things I believe you will experience for the first few days of a long vacation is all the chaos in your mind bubbling to the surface. As the days pass, and you rack up more sleep, things will begin to settle. When you return from your vacation things should be infinitely clearer than the are now, and you’ll have a much better sense of what your goals are, and what you need to do to accomplish them.

My Response to “Are we over complicating software development?”
This question was posted on HackerNews by ian0:
Read More »
A Far Too Brief Rough Outline of How to Approach Single-Date Estimation
In my previous “An Attempt at a Pragmatic Framework for Defining a ‘Senior Engineer’”, in the “A Process to Estimate Work” section I said:
“It is beyond the scope of this post to describe everything that goes into making a good estimate, but suffice to say a senior engineer views estimates as a difficult challenge to be surmounted, and as a result will normally ask for dedicated time simply to come up with the estimates.”
A commenter asked that I write an article on estimation, and this is my feeble attempt to do so.
Read More »
An Attempt at a Pragmatic Framework for Defining a “Senior Engineer”
Brandon Hays’ article “The Conjoined Triangles of Senior-Level Development” made me reflect on all of the Senior Engineers I’ve worked with. If I were to guess, these would be the shared traits that lead others to declaring them “Senior Engineers”:
Read More »