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.