Embrace the Joy in Simplifying

Today, I'm dropping about a dozen tables from our database.  The tables are holdovers from a legacy bit of the previous system that were needed as scaffolding to get the new system in place, but are no longer necessary.  They are not used for anything, and the data are not useful in any way or needed for audit.  Then again, they were not really in the way or costing us anything, right?

And yet I feel a great deal of joy getting rid of them.

Thing is, all team members knew that we needed to do this maintenance, and no one disagreed that these appendix-like structures were no longer needed, but getting priority to clean them up was difficult. The general feeling was that the unused code, data structures, etc. weren't really hurting anything.

There's been a good deal of study around clutter and anxiety, and the internet is awash in articles that link the two.  A system that has a lot of old code and data structures is akin to a hoarder's house full of clutter.  It causes anxiety.  And there are very serious parallels between code clutter and home clutter.

So let me be clear: cleaning up your messes is a priority.  You don't generally think about it, but every time you want to go look something up in the database, your eye has to scan over those legacy entities.  There's friction there.  Do a code search for a class?  You find more entries than you need to. There's visual clutter there that takes time to scan.

Yes, you may not use those classes anymore, but they have references to your framework and other classes, right?  If you make a change, there are more changes you have to make to get things to compile, more places you have to make sure you don't make a mistake.

Having all these extra classes and structures lying around creates a death by 1,000 tiny little cuts. Deal with this infinitesimal time waste enough times a day, and it adds up to real time wasted and real productivity impacts.

So clean up your codebase.  Make it a priority to remove outdated structures that are either legacy or the result of overengineering (which I define as ignoring YAGNI).  Minimizing the number of tables, objects, views, whatever in your system makes the system leaner and more easy to deal with.  It minimizes cruft and code clutter and makes future coding easier by reducing friction.

Better still, removing old untested code increases your test coverage metrics for free!

So please take some time and load some of these stories into your backlog today.

Creating an Ego-Free Environment

For years I've been talking to my teams about "ego-less development".  I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.

For me, ego-less development starts with the recognition that not everything is about me.  All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage.  When we are done writing it, we do not own it.  It is not who we are.  The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.

You can think of software as commissioned art.  Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.

When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write.  Many people take criticism of their code as a criticism of their own person.  While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.

The translation works like this:  What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code.  Something is wrong with it.  So something is wrong with YOU! STUPID!"

If you're a team lead, you need to make sure that the culture changes so the message comes across correctly.  Here's a couple things I've found really helpful in cultures I've been part of:

Freely admit your own mistakes:  Everyone makes them.  It's no fun to make them, and worse to have things blow up because of something you did.  When things do explode, fess up.  No excuses. "I did that. I'm really sorry."  You're looking to demonstrate the correct approach that you're looking for. Lead by example.

Let people know it's okay to screw up:  While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over.  Be honest. Don't gloss over it by saying it's okay.  "Yes, you screwed up.  We've all been there.  We'll do what we need to fix it."

Don't map ownership of specific code to people:  If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code.  Guess you better get in there and fix it." Once the code is integrated, it's company code.  You don't own that code.  Anyone can go fix it.  Throw the bug in the backlog and let the next available dev snag it.

Use positive language, even when disagreeing:  Yes, this is software, and at some point you've got to ship.  Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..."  That's another way of calling someone stupid, if they legitimately disagree with you.  Language and communication sets the tone.  Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits.  "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."

Let's say you even get to Nerdvana and have an ego-free environment.  Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them.  Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.

Not many environments work as one-person bands.  Great work takes great teams.  Great teams are formed by trust.  Check your egos at the door, and build that trust in your environment today!

You Should Leave Your Job

Here we are again.  I'm talking to you.  It's just us here, and no one is listening.  Clear your mind.  Take all your preconceived notions about what you were going to do today and toss them out the window.  What I'm going to say may shock you.

You should leave your job.  Soon.  I mean it.  Start looking today.

Look, you know and I know that life is too short to hate your workday.  Let's make a huge assumption: 8 hrs of work a day + 30 minutes lunch + 30 minutes * 2 for commute = 9.5 hrs of your 16 hour day.  That is 60% of your useful day.  If you eat or work longer or are further away from work, the numbers get worse. The numbers get better if you're willing to skimp on sleep for a longer useful day.

You know that every keystroke you give someone is a gift, right?  In this great presentation, Scott Hanselman suggests you check this out.  Are you giving the gift of your limited keystrokes to the right people?  For the right reasons?  Do those keystrokes match up with your values?  Are you giving gifts that others want and only you can provide or are you buying generic gifts that the recipient will ooze with "meh" over.

I've seen your situation before.  You're dark matter.  You're a 5:01 developer.  When you got to the organization you're in, you loved the first project you were put on.  You were hired specifically for that project, so it met your idea of what you'd be doing when you signed on.  You put in lots of time learning, showing people you were excited, showing you could be counted on to deliver.

You were enthusiastic.

But that was years ago.  That was a couple CTOs ago.  That was a couple technology strategy direction changes ago.  The organization has moved on and you've adapted to provide it value, but maybe your day-to-day is not what you wanted to do.  Shoot, it's a convenient commute.  The compensation's right.  Family health matters made it inconvenient to take on a change at that time.

You like what you did at the organization in the past, but now there's very little to do.  You're in maintenance mode for the product you were hired to build.  Management appetite for new development is nil because of cost cutting.  You've been told to keep the lights on.  Leadership doesn't want to spend time adding new features because they would rather buy a replacement system, but never seem to actually complete the research to buy that replacement, resulting in continued use of subpar tools, and missing opportunities to sharpen developer chops.

You're a developer, but because of "budgetary constraints", the organization is not allowed to staff a team that develops software appropriately.  So you are doing business analysis or QA, because there's no one in those roles.  In agile teams that's something that's expected of everyone, but your projects aren't agile.  You spend a lot of time writing up documentation that never gets used or read.

The excellent team you signed on with?  Excellent teams are an unstable equilibrium.  If you were on a tiger team of development that does everything right, did your organization split it up to "seed" the talent in multiple places, not realizing that it's the team that did things right, not the individuals?  Great people working on excellent teams get recruited to join other excellent teams.  So maybe your team fell victim to entropy.

So that team is no longer.  Maybe that was many reorganizations ago, before many different sets of leadership came in and tried to optimize output of a fixed group of resources.

Maybe your organization favors butt-in-seat over other productivity metrics.  For that reason, you can't work from home, contributing to that feeling of wasted commute time.  Collaborative technology is discussed, and maybe even experimented with, but because not enough people are using it, it's never optimized.  Time-shifting is not allowed to enable you to work at your most productive times.

Maybe you're on a support rotation.  That wasn't in the original sign-on agreement, but "You know... We all have to be team players", and you don't really mind since it's not all that often.  Although when it does, even though comp time should be an expectation, it's never discussed.

Yeah, maybe this describes your situation.  Maybe only some of it does.  If it does, however, you should leave your job.

But maybe you're not convinced to move.  You're too complacent.  You're comfy.  This job thing is a solved problem and you don't think you'll ever really need to look for another one.  You can coast out your career on your current skill set.

Maybe, but I've put together a few signs that it might be time to consider moving on.

Signs

• Don't like working on what you're working on
• Don't like who you're working with 
• Don't like your immediate manager
• Don't feel as if the discourse is civil or nonconfrontational 
• Don't believe in management's vision or goals
• Don't believe in your management's ability to make good decisions
• Don't feel valued for your contributions 
• Don't feel the tasks in front of you are very exciting
• Don't feel focused enough on any one thing
• Don't have clear reporting structures; have overmatrixed teams
• Don't feel like your organization can prioritize
• Don't feel like productivity is as important as appearance
• Don't feel like the organization is moving forward quickly
• Don't feel like the organization makes data-based decisions 

I read the following as symptoms of organizational dysfunction.  To change any one of these is like moving a cultural mountain and require clarity of vision and charismatic leadership from the very top.  I don't think that mid-level management in any organization can change these effectively.  If you recognize a lot of these, it may not be just your position in jeopardy; the whole company may be in trouble long-term.

Symptoms

• Very peaked/deep org structures indicate a problem with reporting.  Need a low ratio of managers/doers.
• Lack of information flow
• Lack of recognition
• Lack of celebration for hires or promotions
• Lack of visible employee enthusiasm
• Lack of unity of processes across divisions
• Too many junk drawers 
• Too much reliance on transition plans (which don't work) 
• Lots of Not Invented Here silos of experience 
• Headcount is kept flat regardless of technical investment or debt reduction 

So if any of this resonates with you, consider leaving your current gig.  Fast.  There is too much demand in the development industry to spend time in an organization where you're not happy.  Some organizations just don't get it, but there are plenty that do.  Find one and let the ones that do hire unenthusiastic, unmotivated shlubs to barely work until they go out of business or get sold to a competitor.

If all of this resonates with you, call a recruiter today.  Shoot, call me.  I know enough recruiters and folks at good places to be a good resource, and I'm happy to help you find your passion.  If you just want to talk, I'm here too. You'd do well to find yourself a mentor, too.

And if you're happy with your gig, good on you.  Come on out and be part of the community.

I just want you to be happy.  Yes you.

How to Write

I seem to have been writing a lot lately.  Just the other day, I put out about an 1800 word essay on my blog. I did this because it’s something I've been thinking about, and I follow Scott Hanselman's philosophy on multiplying your effectiveness (it's a 40 minute presentation, but it really is worth your time, no matter what your field).  One of the tips boils down to this: if you have an opinion to articulate, and you’ll want to say it to many people, it’s worth it to spend a little time to polish your thoughts, write it down, and then you can send it to many people at once, and have it available to refer to.

I don’t know how many times I've posted the same points or ideas to Facebook, talking to different friends. The barrier to entry is so darn low to hosting your ideas permanently online that there’s absolutely no reason not to publish your thoughts.  Blogger?  Free.  Tumblr?  Free.

And I've been doing that a lot more.  It occurred to me that I should be encouraging more people do the same, but then I figure they will want to know, “How do you write?  I have thoughts, too, but how do I actually get them on (electronic) paper, organize them, and make them sound good?”

Here’s my secret: I don’t.  Well, not really.

My recipe for writing is as follows:

• Have some thinks
• Write them down somewhere online (as I mentioned, there are free platforms out there)
• Edit (this step is entirely optional)

So let’s break it down:

Have Some Thinks
You'd think this was the hardest part.  I do.  I mean, I did.  Maybe you have this idea that you have to have an original thought, and it has to be a well thought out thesis, or that it has to be so well-researched that it has to be bulletproof.  Here's the real truth, however.

It's a blog post.  It doesn't have to be your Ph. D. defense.  It doesn't have to stand up against a tide of questions or a barrage of counterarguments.

Think about the last argument you had with a family member where you had a difference of opinion.  You probably went back and forth and the conversation diverted here or there into topics unrelated.  Think of a blog post as your opportunity to get your side of the conversation out without interruption.  So you can get your whole opinion out without being interrupted.  This is a great way to get your opinion out, get it off your chest, and maybe even continue a constructive conversation.

Write them down somewhere online

Ok, these steps are so easy I can give you a recipe:

• Pick some blogging platform. I obviously use Blogger, but Tumblr, Wordpress, whatever.  Just pick a free one that lots of other people are using.  
• Pick a sweet username or blog name.  This can be your name or your topic, something hipster, or something classical.  Anything that you feel represents you and what you're most likely to write about
• Write a little test post.  My first post on my first blog (this is my third) was a trivial little nothing post that I can still see and occasionally look at as the genesis of ... wow, 10 years of writing.  Don’t share this test post with anyone.  Just know it’s there.  Let the fact that you've published your thought to the web sink in.
• Next, start getting those ideas out.  Whenever you have something long form to say to someone, say, in an email, blog it instead and send them a link.  Put together a lot of drafts and have them ready to add to.  Whatever you need to do, get those ideas out of your head and onto the page.  Bullet points, fragments, whatever.
• Flesh out a post.  Click publish.  Repeat.  It's not so hard.  Eventually, the problem will be that you have so much to say that you don't have time to say it.  Trust me.  It happened to me, too.
• Publishing gives your thought a permalink, somewhere you can always refer someone to.  Another big benefit to doing this is that you can refer to your former thinks whenever you want without having to rewrite them.

Edit (optional)

If you want to, please feel free to edit your thoughts.  Take some time to proofread them, spell check them, check them for grammar.  Make sure you don't say "like" too many times, or whatever speech pattern you have that doesn't translate well to the written word.  But remember, editing is optional.  Here's why.

Ok, so you’re thinking your thoughts are all disjointed, and that they need editing.  Maybe that's true, but don't let that be the reason you don't publish them.  Perfect polished thoughts can be left to the philosophers and linguists who look to distill ideas into their perfect essences.  Your idea doesn't have to be perfect or bulletproof to have value.  Heck, you thought it, right?  It was good enough for that email conversation you were going to have.  Why not have that conversation with more people?

Afraid you might be wrong?  Well, maybe better to find out than to be wrong forever.  Worst thing that happens if you're wrong is that you learned something.  Worried people won't think you're a genius?  Here's a hint.  They already don't.  Don't worry.  You're not a genius.  But you are valuable, and your opinion matters.  You can have great thoughts even if they're not entirely fully formed.

So get your voice heard.  Speak up.  And then tell me, because I want to hear what you have to say.

Takeaways:

You’re going to have opinions, so don’t be shy.  Share them.  Write them down.  Put them out there.  Share your knowledge and talent with the world.

Or at least with me.