Rant 6

Take a business who's core competency is not software/systems, for example a manufacturing company.

This business may have started from humble beginnings, assembling parts in the garage, selling them online.  Eventually, the company needs a website, then an inventory management system.  They'll start with spreadsheets, using Excel to manage and track everything.  

Eventually, they'll find that this doesn't scale.   Next, they'll purchase "my first ERP" system.  One aimed at small businesses.  

Eventually, you hire a person to manage your IT needs, but you watch him closely and give him very little respect.  He wasn't brought in as a business partner, but as a contractor, to do "spot work".  You still haven't realized that your IT needs will be a forever endeavor, an ongoing need.  As much as you want it to be spot work, where you shell out a one time fee and it's "done", you have the sinking realization that it will never be this way.

This single person who keeps IT running is buried, so you hire another.  Then another.  One of them eventually cobbles together a little custom piece of software to solve a specific problem, and WHAM!  You are now in the software business.  And you can never get out of it.

In 2011, Marc Andreesen famously declared that software is eating the world.

Five years after that, software is still eating the world.

If you want to play in this world, and have a development team embedded in your organization, you probably ought to learn how to engage with them, or hire someone who does.

But maybe you don't have to.  Because in 2019, Forbes says that Software Is Eating The World, But Services Are Eating Software.

If, as an organization who never set out to be a tech company, you are frustrated by trying to be one, then just stop.  It's not your core competency, it never will be, and you don't want to pay for it.

Fold up now, and just use 3rd party services.  As they say, if it flies, floats, or fucks, it's cheaper to rent.  If it compiles, deploys, or whines like a prima donna software developer, it's also probably cheaper to rent.

Rant 5

Developers have a reputation for being whiny and entitled.  I'd argue that this is simple economics.  The people who openly criticize management are the people who are not afraid of losing their jobs.

That is, those who can easily find another job are more vocally critical.  If the market for devs was dry, and BA's and PM's were in high demand, suddenly the devs would be quiet and fearful, and BA's would be more apt to call out something as "broken".

Simple supply and demand.  

See "The Dead Sea Effect",

…what happens is that the more talented and effective IT engineers are the ones most likely to leave — to evaporate, if you will. They are the ones least likely to put up with the frequent stupidities and workplace problems that plague large organizations; they are also the ones most likely to have other opportunities that they can readily move to.

What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.

Rant 4

 Adding an improvement to an existing system without shutting off the old way is a classic mistake.  Mature teams and leadership make it a point to replace, not append. 

If you don't have the obligation to be backward compatible, consider yourself lucky enough to be able to shut off the "old way".  In fact, the "new way" should not be considered complete until the old way is completely gone.

Ask yourself, when is the last time you truly decommissioned a component of your technology stack?  If users have multiple ways to achieve the same workflow, this is a smell.

This typically stems from inability to measure the usage of your product.  You're afraid to take something away, because some user might scream that their cheese was moved.  You should know whether or not it's in use with some basic logging and instrumentation.  If you don't have that, then get it.  

Code is not an asset.  Code is a liability. Strive to reduce liabilities. Your users will adapt. 

Rant 3

 Let me get this straight.  You're asking "senior developers" to monitor a help desk that is flooded with incoming "issues"?  And you also want that developer to focus on his project?  And you're mystified as to why you can't seem to 

a) hit a date on these project "commitments"

b) retain any senior level dev talent

Rant 2

 Look around your dev shop and identify anything that qualifies as a "leveling up" or productivity amplifier.  Chances are that if you work for a non-tech company, in a traditional IT cost center, then few of those were initiated by management.  

Automation, CI/CD, IaC, even source control.  Productivity tools like screen sharing, screen recording, wiki's for knowledge sharing, rich chat clients, etc.  These are all typically grass roots efforts where someone had to "fight" for it.  And guess what, that person is no longer with the company, because he/she expended all of their  energy and political capital to put that thing in place.  That team member forced the organization to level up, against its will.

Management will say, "that guy was a pain in the ass".

Rant 1

Here's one flavor of how work gets defined in an IT shop.  Warning, this flavor tastes like shit.

1. Dream up a feature or capability that you want
2. Ask an individual developer (not a team) for an estimate on this vague request
3. Brow beat that developer until you get an estimate
4. Call that estimate a commitment
5. Act indignant/surprised when it all doesn't magically come together by this date
6. Double down on your position.  "If only that lazy developer had worked harder and taken the date seriously"

This is a pathetic excuse for management, and a complete mockery of leadership.  Yet, I'm afraid it is common.  It's what you get when the decision makers have no understanding of software development, and they stubbornly cling to the dream that they can have certainty and predictability.

Low effort networking (the social kind)

Networking.  It's important.  We've all heard about the value of networking.  Some even say that the real value of a Harvard education is the connections you will have made upon graduating, plus access to an alumni network.  After all, are they really teaching math better than any other university?

As a software developer, I had originally thought the value of attending a tech conference came from consuming information about technologies in a classroom type setting.  And I enjoy that.  Oh cool, look, a talk on Clojure and functional programming!  I don't get to use that at work, let's attend that one.

But, as the availability of information continues to proliferate, I find that I prefer to watch a Pluralsight video on a topic of my choosing, rather than sit in a lecture.  I can focus better, and more efficiently consume the content.  So, for me, the question becomes, "What value is there in attending a tech conference?"

On a side note, what percentage of attendees are developers?  There is probably data out there somewhere. One can only speculate.  80/20 rule may apply here.  I'd say at least 20% of attendees are not developers.  That means that when they look at code, they may as well be looking at hieroglyphics.

Ok, so back to networking.  As a developer, if you believe that networking is a worthy endeavor, and you are going to a conference, then who do you want to network with?  Presumably someone with whom you can form a symbiotic relationship.  What do you have to offer?  Maybe your employer is hiring and you can offer a referral.  Maybe what you have to offer is your own development expertise and services. 

Is your boss in good standing?

 Interviewing as a candidate is precarious.  There are 2 modes you typically find yourself in.  There is the "I just need a job, any job" mode, and there is the "I have a job, so I can be choosy" mode.

For more junior folks, they will typically just take what's offered.  Make some money.  Learn some things.  If it doesn't work out, move on.  After you repeat this pattern a handful of times, you begin to identify some trends.  You start to see that organizations are just collections of humans.  Humans are flawed.  Organizations are exceptional at a lower rate than individuals are.

Upon accepting a position, you generally have no idea what you're walking into.  After the first month on the job, you'll have a little more clarity.  You'll begin to notice some major red flags, and then there will be a voice in your head that says "would I have accepted this job if I had known about this?"

One such red flag is discovering that your manager is not in good standing with his manager.  Great, I just got hired by the guy that everyone views as a stooge.  Now I'm the stooge of a stooge by default.  Could I have vetted this situation more thoroughly prior to taking the job?  You can't exactly ask in the interview "So, who's the village idiot among the senior leadership team?  Is it you?"

But there are some hints that you can glean.  If the hiring manager has recently been promoted, that likely bodes well for you.  He's earned some credibility in the eyes of decision makers, and he's growing a team. This sounds like a good opportunity.

On the other hand, if the hiring manager reveals to you that she has been with the company her entire 20 year career, and has just hung around as a passenger on the ride, this is a smell.  For one, we all know familiarity breeds contempt.  This person has likely been the fixture among a cast of characters that are rotating around her.  She's perpetually upset that they brought in yet another outsider for the big role above her.  She felt like it was her "turn". 

This may be a controversial opinion, but staying put in one company for decades says something about a person.  It says they like to be comfortable.  It says that they don't like change.  It may indicate that they aren't hire-able outside the company.  Life is fluid.  Standing still is rarely the optimal strategy.

Everyone knows that an interview is a two way street.  Most people agree that the company is interviewing the candidate, and the candidate is interviewing the company.  I am proposing to simplify this.  As a candidate, you aren't interviewing "them".  You are interviewing the individual, the hiring manager.  After all, a company isn't something you can ask questions of.  A person is.

A person doesn't quit her job, she quits her manager.  What's the inverse of this?  A person isn't hired to work for a company, she's hired to work for a manager.

Make sure you don't fall for classic traps, such as the company's name recognition, perceived stability, or overvaluing the compensation.