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.  

Business analysts hate this guy!

In a conference room somewhere in corporate America, a software developer was asked to give estimates on vaguely defined feature requests.  And then, get this, he had the gall to probe for more information.

The business analyst quickly grew impatient, and regained control of the meeting.  "Seems like a size small to me,"  he said with a huffy tone.

The developer looked again at the screen.  It read "Implement custom rules for new client".  He thought to himself, "what difference does it make what the estimate is?  How did that #noestimates guy on the internet get anyone to listen to him?"

Another developer chimed in "I think it's a medium sized effort."  Our hero nodded along indifferently.  "How long does a medium take in days?" the boss asked.

There were a million holes to be poked in the user story, but sadly no one in the room had the necessary attention span to talk about them for more than thirty seconds.  As is tradition, everything gets a meaningless estimate assigned to it. The developers will be left to their own devices to sort out the particulars when they begin work on it, 7 months from now.

Immediately after implementing his best interpretation of the feature, the dev will get to explain to the QA how to test it.  The QA was too busy testing to be present in today's meeting.

"Ok, I've got to cut this off here, I've got another meeting in 5 minutes" the BA announced, "We'll have to finish up these last 6 items in an impromptu meeting.  But, they're easy ... I mean they're easy to talk about."

The developer walked out to the parking lot, and kicked a can for about 50 paces before discarding it into the grass.

Metrics

The state of the IT industry is quite sad.  The plight of the IT cost center is that it doesn't have any good way to tie dollars spent to dollars earned.  If I invest $1M in IT, how do I equate that to a business outcome?  I have to wonder, couldn't I have gotten the same business outcome for half a million?

IT managers are desperate for metrics.  They are starving for some way to demonstrably show that they are not squandering money.  It's the old "build things right versus build the right things" argument.  Because IT doesn't have a large stake in determining what the "right" things are, they are left with determining whether or not they did the best they could with what they had.  And anecdata will not do.  We need metrics!  They don't necessarily care if they are meaningful metrics, because it's better to be the guy with bad data than it is to be the guy with no data.

What is our defect rate?  How do we measure quality?  Productivity?  How good are we at onboarding new team members?  Are we up to snuff on all of our compliance concerns?  Let's get some process around this stuff!  That's likely what you will hear after a big company has acquired a few smaller companies.  The smaller companies flew on light (no) process and got by on their skill and being nimble (wanted to use the word agility but the term is too overloaded).  These small companies got to be profitable enough to become acquisition targets.  Then when they get acquired, the new IT manager, who has never built anything from the ground up, surveys his mixed bag of teams with varying degrees of process rigor and maturity, and decrees that we are going to drive consistency. 

The talented developers groan.  The ones who crave a little autonomy are now facing the prospect of becoming a mindless ticket monkey.  But isn't that what it's really about?  Reducing your dependency on skill and talent.  Predictability is now of the utmost importance.  Predictably mediocre is better than sporadically excellent.  And that has to be a conscious choice, doesn't it?  The people pushing this type of process rigor can't really think that they will be breeding a vibrant culture that attracts bright minds, can they?

Keep in mind that I am speaking specifically about the IT Cost Center in the context of a medium sized company pushing to become a big one.  Picture a company inside of the healtcare/insurance/banking/finance space that was recently acquired. 

What is the bright side here if you happen to be one of those knowledge workers who likes to color outside the lines?