10/07/2015

I've Moved. Sort Of.

Going forward, I'm going to be providing content almost exclusively on http://www.simpleprogrammer.com for a while. I realize this might be a little contrary to the advice of having a blog, your own website, etc. But, John has a team of editors, layout, and graphics people - and people generating ideas, and a huge audience. And I just have me.

So, in order to continue to grow as a writer and as a presence online, I'm going to shift gears and focus my attention on putting out amazing content over there. I'll still put up links on this website to point you at my content, and I'm still happy to answer any comments or questions that come up here. This is just me doing my best to find my voice and my niche.

Look forward to keeping the dialogue going!

10/01/2015

Hiatus

I've been dealing with a family medical situation over the last several days, so writing is pretty far from my mind. You can find lots of good writing in these places instead, if you want to:

I'd love to hear from you those places you go for professional enrichment, too.

9/24/2015

Guest Blogging

The wonderful people over here: http://simpleprogrammer.com/2015/09/23/my-business-is-software/ have editors and graphics people and all kinds of other neat stuff. So, there's a good chance you'll see me writing over there a bit more, and here a bit less, until such time as I've got enough time to write in both places.

That said - enjoy my latest over on John's blog. I like how it turned out!

9/17/2015

Deadlines

My normal time for content to go live is 11:00 AM CST every Thursday. It's Wednesday night right now. My family have been sick and my job has been intense. But, one thing I know about blogging from my audience so far is that consistency is key. So I've imposed a deadline for myself to get content out at least once a week. This is what I call a well reasoned and natural deadline. The other kind of deadline is an arbitrary artificial deadline created by project managers who have to prove that the company that hired them isn't "wasting" their money. Avoid these deadlines like they are a three headed venomous snake. Trust me. They bite.

What's a "Good" Deadline?

I'm not opposed to deadline management if they come in the form of the end of a sprint or time box. The amount of work that goes into a sprint before the sprint expires might change depending on the size of the stories in the sprint. But if you do traditional sprinting, the end date of the sprint should always remain fixed. And if you use that during a continuous delivery cycle, the end of a sprint also means a production deployment. Then you have a few things going for you that are "hard dates" - specifically the sprint retrospective at the end of your sprint and your sprint planning day at the beginning of the next sprint. Or, in my case - motivation to get my writing done for my lovely loyal readers. Thanks for being loyal - hopefully I will continue to not let you down.

One other kind of deadline we can't avoid, no matter how badly we want to, come from forces external to our project itself. I currently work in the higher education industry. If FERPA laws suddenly change and we have to change our system to not violate them by a certain timestamp, then that's a hard deadline. And we can't miss it. In a healthy organization what this means is that we bump out other feature scope in favor of the new regulations. In a not-so-healthy organization this means massive amounts of overtime and lots of energy drinks.

What's a "Bad" Deadline?

Here's how to spot a bad deadline in the wild. Be warned, they can sneak up fast and bite you from out of nowhere. They come camouflaged as "just give me your best estimate" or "we have a target date of..." In general, you can tell a deadline is arbitrary or non-realistic if it's based on something that:
  1. You or your closest team representative didn't come up with or help come up with as a critical, non-movable deliverable because of the ramifications it has legally or on the bottom line
  2. You did come up with it as a best guess estimate and your project manager puts it in big red letters on the calendar as the "Go Live" date
  3. You're on a waterfall project. Yes, those still happen. Yes, the deadlines inside of them still bite.

Managing Up

Even if you've got the three headed snake of bad deadlines looming in your sights, you can still manage up to make the deadlines approaching more realistic within your own circle of influence. There are several ways you can still have an affective release date that matches the timeline, but you have to do a really good job communicating expectations and clearly defining what scope you will hit on time. Project Managers love to do scope management, it's yet another reason they get paid. So, if you tell them that you need to adjust scope to meet their arbitrarily decided upon release cycle, make sure you can clearly articulate your reasoning. And make sure you're ready to deal with someone who wants a very good reason why your estimate wasn't handed to you from a higher power and created with magic all-knowing dust. If you can clearly articulate, in a quantitative way, why your initial scope cannot possibly take place in time for the deadline - it's up to the project manager and product owner (hopefully there is one) to decide which scope needs to go into phase 2, or 3, or whatever. In all reality, what you're doing is your best to "bend" the project management SDLC into something a bit more sprint-like - but morestill have to do so in a charismatic way so that you're still "meeting your deadline"

Closing Thoughts

Deadlines can add emphasis to important things that really need to be finished on time. They can also add stress to things that really shouldn't be stressful. I'd love to hear more about your own deadline demons and successes, feel free to comment!

9/10/2015

Sick Days

While I imagine at least one or two of my colleagues share my daydreams about merging our consciousness with robots, as of now the human race is undeniably and without any doubt, human. While this means that we have all sorts of human ways to fail (and succeed) what I can say is that nobody on the planet can avoid getting sick. Sometimes the only thing that our bodies allow us to do when we are sick is sleeping. And recuperating should always be your first goal whenever you get sick. But, there's another little thing that comes with sickness - boredom. So, here's some boredom fighting ideas that don't require your awesome brain to be running at full throttle, but also aren't going to make you feel like you're wasting time because you are sick.

Learn Something

Books

Nonfiction

I really like this book list: The Ultimate List of Programming Books. However, it doesn't include Team Geek which is one of my favorites related to working on programming teams.
The amount of non-fiction writing out there could fill several life-times of nonstop reading. Some of it really teaches us interesting things, some of it is really dry, but in general if you're reading something in the non-fiction category you're probably going to learn something. Even if it's only the title of a book you can't stand to read.

Fiction

I don't spend much time reading non-fiction any more. I'm a huge Star Wars fan, and as a kid I spent a good deal of time reading all of the novels that had "Star Wars" in the story-line somewhere. Thanks, Disney, for making all of that knowledge obsolete! Here's the thing, though. Even though that trivia I did have about Mara Jade and Admiral Daala really doesn't amount to a hill of beans regarding practical factual knowledge, spending that time reading taught me all kinds of things about how to communicate in writing. By reading the written communications others had spent time authoring and editing I spent time with "good writing". I'm not talking about the content, really - I'm talking more about the organizational structure, the syntax, the diction, the tone, and all of those things that transcend content itself. Human beings need to communicate with one another. Universities have entire degree programs - and advanced degree programs - dedicated to the study of the way we communicate. If you want to learn a little bit more about the ways we communicate ideas to one another, you can't go wrong by reading. Even if it is something silly or "non-academic" or whatever you want to call it. Here's some quotes written by better writers than me on the subject: 20 Surprisingly Profound Quotes From Fantasy & SciFi.

Documentaries

I don't really spend much time watching the youtubes or regular TV shows these days. By cutting TV (and specifically, the ridiculous amount of advertising that comes with it) down to a very limited selection of my most favorite things, I've bought myself a significant amount more time to get things done, like writing this blog. However, during sick time sometimes its pretty difficult to want to do anything besides lay on the couch and stare at the ceiling (or a TV). Even if you find yourself in this position, you can still spend time learning all kinds of crazy, interesting things. There's a channel on YouTube called Ted Talks - it will most certainly get your brain going.

Make Something

Blogging

Sitting at a computer desk to write may not be the first thing that comes to mind when you're not feeling well. But, if you've been keeping a regular blog such as I have, sometimes it feels good just to let ideas flow out onto a page and then come back to them later for editing purposes.  Even if you don't go about writing a full-fledged blog article while your hacking up a lung, you can use a mind mapping tool like XMind to capture your ideas to make them more concrete later.

Creative Hobbies

One of the best outlets I have for myself is my sketchpad. I really enjoy drawing, and others enjoy what I draw for them. In general, I tend to make a drawing and then give it away - because it brings a smile to other people's faces and it makes it so I can stop being a perfectionist about it! When I find myself with unfilled down-time, if I'm sick of reading, writing, or learning in general, I still don't tend to turn on the TV. Instead I pick up my pencils and drawing pad and get to work on something to activate my right brain. As programmers we have to make use of both halves of our brain - anyone who says we're not creative individuals hasn't ever seen some of the cool ways we solve complex problems with a series of simple steps. Creativity is a huge part of our profession, so if you find something that you enjoy which exercises the creative half of your brain you're helping your creative problem-solving side too. I know several programmers that are also musicians - so making music is a good outlet too. Creativity is part of who we are, and sick time - at least for me - is a great time to embrace it.

Your Regular Job

If you've called in sick, don't work. I bring up this point solely because I've been guilty of doing exactly that in the past. I call in on a sick day with a blazing fever, but decide that I've got a little bit of brainpower so I can get task XYZ done today without any interruptions. Yes, you're probably on a paid sick day so you're still "getting paid" to do this work. But nobody at your office is expecting you to do any work at all. Not one person. Doing work for work while sick is a little like stealing from yourself. Also, the normal stuff you do at work isn't likely to help you mentally recuperate, either. Do yourself and your employer a favor, set aside that thing you were working on at the office and do something else. Sick time is supposed to be recovery time.

9/03/2015

How Do You Define Professionalism?

Soft Skills Quiz : Week 4. The statement made as item 4 on the quiz: I act like a professional instead of an amateur. The Merriam-Webster dictionary defines professionalism as

the skill, good judgment, and polite behavior that is expected from a person who is trained to do a job well.
While not altogether the longest definition you can find in a dictionary, I still think the meaning behind it packs quite a punch.

Well Trained Skill

While a good majority of professionalism actually comes in the form of soft skills, the one thing that nobody can argue with is proven tactical skills. I once worked with a complete jerk. He made it hard for other people to get the job done if they had to interface with him as a team-mate. However, when he was allowed to be isolated and function as a solo-unit, his hard skills trumped just about everyone else in the company. He's definitely one of the most technically apt programmers I've ever met. Do I want him on my team? No. But he gets hired for important work because he's very VERY good at writing code. Depending on the needs of an employer, sometimes the professional soft skills get overlooked in favor of ridiculously good hard skills. Granted, I have my own opinions about toxic team-members. But there's plenty of evidence in our field to suggest that not everyone needs soft skills to get by.

Good Judgement

Internet Etiquette

We all have bad days. We all have our outlets for ranting and for venting. The first and most important thing to keep in mind when you need to rant - choose your medium wisely. The millisecond you put your comment out on the internet, think of it as permanent. Someone will find it. Most likely, someone will find it that you didn't expect would ever see it. Posting a picture of yourself (or your room-mate) sloppily drunk, while potentially hilarious at the time, certainly won't get you the positive attention you prefer at the office. In fact, if at all possible just avoid those kinds of embarrassing situations in the first place. Separation of work and life still happens. But you're fooling yourself if you think the things you do at home or with your friends are entirely off limits to your employer. Unless you have a strict and very locked down social media policy, your behavior around others will reflect outwardly towards your workplace. Be careful about the activities you choose. It's OK to be silly or stupid. Just remember that someone else is going to notice, so make sure you're OK with whatever it is someone else will see.

Communications Professionalism

Besides avoiding drunk-posting on Facebook, there's other areas in your career that depend on good judgement. Think, for a minute, of the different communications channels that you use every day at work. I, for one, have instant messaging, email, phone, texting, and direct human contact. Now, think about this situation for a minute. Your web application just went entirely belly up. What's the correct order of operations to get everyone's attention? If you work in an office, the first thing I'd recommend doing is running down the boss personally and getting his attention face to face. Then, immediately follow up with a very high priority email to everyone that needs to be involved in fixing the problem. Whatever you do, DON'T get on Facebook/Twitter and say "ROFL our server crashed!" Bad idea. Very, very bad idea. The richness with which you communicate your message to the intended audience matters deeply. There's a scale I like to follow that helps: Face-To-Face>Video Conference>Telephone>Instant Messages/Texting>Email. There's also plenty of literature and advice as to how quickly someone should expect you to respond based on the kind of communication they want to partake in. Here's a pattern I want to get better at enforcing:

Face to Face (or two-way phone) conversation: The best way to get my attention immediately and have zero delay expected. But you might have to tap me on the shoulder if I'm rocking out to Beethoven.
Instant Message: 15 Minutes or less after my status shows "Online". This only applies at work. I don't do much IM replying at home
Voice Mail: 1 Hour or less after I'm back at my desk
Email: 1 business day
Social Media Direct Message Unpredictable. Please don't use this for anything important at work. Because I can't promise I won't be ignoring it for a week and a half at a time
Snail Mail: Wait, what? I'll probably get back to you eventually. I can't give you any idea how long I'll take because I don't think I own any stamps. Where does one even buy stamps...?


Polite Behavior Getting back to the way you interact with your colleagues, politeness matters. If you have to leave a voice mail for someone, use courtesy and make sure they know the best way to return a call back to you. Also leave a day and time you intend on attempting to contact them again. That way you set a clear expectation that the other person doesn't have to get confused about. Something like

"Hi Mr. Johnson. I'm calling about the widget we promised to your team in October. I have a question about it, and in order to keep us on track for its delivery we need to have clarification no later than close of business, this Friday, September 31. You can always feel free to reach out to me at 555-555-5555. If I haven't heard back from you by close of business Thursday, you can expect to get another call from me Friday morning. Thanks!"


Politeness extends to all aspects of your professional behavior. Whether on a phone call, writing an email, or responding to an instant message, manners matter. Please, thank you, and you're welcome really go a long way to making a conversation more amicable. And, as far as I'm concerned, vulgarity is just !#@% stupid. I realize that most words are just "colorful metaphors" - but if you want people to take you seriously as a professional, generally speaking cussing is out of the question. Sure, I've been known to drop a colorful metaphor on a rare occasion. But in general because that's not my normal pattern or something I keep as part of my vocabulary, it gets people's attention when I use those words. It's rare. However, even in the rare case where vulgarity manages to slip in it's even more important to follow it immediately with polite kindness. Getting worked up and turning explosive places everyone on the defensive. Even people who don't really need to be. And that, in turn, can lead to strong negative emotions that lead to poor business decisions.

8/27/2015

Quality Testing Is The Best Investment

There's no doubt in any software engineering practice that spending money on the quality of the product has to happen. After all, a feature that doesn't work the way it's supposed to, or just flat out doesn't work at all, really isn't a feature at all. And, hopefully at the very least we won't write code into our systems that cause the systems to crash entirely. That would most certainly destroy customer trust. We have to have quality in software, whether we work for internal engineering departments or whether we're marketing software as a product. Games, productivity tools, health tracking tools, and all kinds of other software depend on software to remain profitable. Instead of thinking of quality as expensive, we need to think of it instead as the much less destructive cost than a customer finding a failure in quality. This article does a pretty good job explaining why it's much more expensive to fix a bug the later in the process it's uncovered. Quality isn't an expense. It's the most critical investment you can make in the software portfolio you offer. There's two kinds of investing testing I want to cover, and their related components. Interactive testing and automated testing.

Interactive Testing

There's several different phrases or quotes that all have the same general acronym in them: QA. For example "has QA tested this yet?" or "What did QA say about the latest features?". In general when we talk about "QA" we mean our team of interactive testers. This is a group of people with a test lab of hardware where they exercise the software by inputting all kinds of nonsense (and valid input too) to make sure that when gremlins hit the software, it won't implode. They have requirements and acceptance criteria, build test suites, and make sure that when Joe User opens the application they don't immediately close it again. No matter how good your automated test suite is, we always need interactive testing to verify that, as human beings, the software behaves itself.

What makes this a good investment? Well, first of all when you have a strong interactive testing team they will build automated tests out of the manual tests cases that they have created. Then, going forward, you have the ability to plug in regression analysis into your continuous integration build that includes testing that happens very close to the user's reality.  For web applications (my wheelhouse) we usually use a tool such as Selenium to drive these interactions.

Automated Testing

Unit / Functional / Integration Testing

There's plenty of people way smarter than me that have taken the time to address the ratio of unit vs. functional vs. integration testing in your testing suite. My main goal is to get unit test suites that do a great majority of the testing of each class and method within a class. When I talk about these kinds of tests in general, what I mean by this is tests that can be run by some combination of a test harness (jUnit/CodeCeption/nUnit) and some kind of dependency injection container (Spring/Symfony/vNext). When you're writing pure unit tests, the DI containers should not be initialized by the test harness. For some functional tests, and definitely for integration testing, it's important to ensure that the proper usage of the objects placed into the DI container is correct. For the most part, the highest bulk of automated test harness code should be unit testing that mocks away any dependencies it requires. Prevention of repeated regression is the main and most obvious benefit that comes from testing created in a test harness. Furthermore, with a proper test harness production bugs can follow this workflow: verify bug->reproduce bug using test harness->make red test turn green by refactoring. By using this workflow, you assure yourselves that, as far as regressions go, one less will take place. Now, instead of making it into QA or out to the client, your automated test can inform you immediately upon check-in if any new code violates an existing test.

Performance Testing

Applications have to be fast. According to Microsoft research, Goldfish do a better job of paying attention to one subject than human beings do. You have 8 seconds (or less) to ensure you're delivering the right value to your customer. Otherwise they're going to context shift and look for something else more interesting to pay attention to. 8 seconds. To load the most critical insights on thousands/millions/billions of data points. If you don't think performance (or perceived performance) matters in your application - you're going to end up regretting it. People will stop paying attention to it, and then you won't have customers to work for any more. 
Source: Microsoft Attention Span Research

Penetration Testing

Ignoring security implications of software seems to me a bit like sending a cow out into an alligator infested river and expecting it to make it safely to the other side. Read the news. You'll see what I mean. After all, one of the many critical aspects of quality is security. Many software industries can even get into significant legal trouble if the software doesn't properly protect its users. HIPAA protects health records. FERPA protects education records. Imagine if you worked for a company making one of those kinds of software, and sensitive data got out. At that point your company's reputation has been tarnished to a point where recovery will take a very long time, if you can even recover at all - and while you're working on spending a ton of money trying to repair the damage, you also have legal regulators to contend with. The expense of a security breach cannot be ignored, just ask Target. The cost of implementing the best security measures we can on the outset hardly seems like any kind of expense at all when you compare it to the risk of not raking security seriously. How much more likely is it Target wouldn't be in the public's cross-hairs if they had spent $148 million dollars on a security improvement initiative? And they'd have a reputation that didn't include "don't use your credit card to shop there."

Peer Reviews are Critical Too

In essence, the fastest way to get quality is to have someone sitting over your shoulder watching you write every line of code you're writing to get a feature out the door. This assures two things: 1) no one person has all of the knowledge about a given feature 2) the person writing the code will write differently because they know they're being reviewed in real-time. Pair programming gives us the opportunity to have a pilot/co-pilot pattern to work from. But, it's very hard to implement practically - and also very expensive, because you have to have "twice as many" engineers to get the software into production. But - with twice as many engineers, the likelihood of regression happening from any one given check-in goes WAY down.

8/26/2015

Guest Blogger - Outlier Developer

I'm lucky enough to get to be a guest author here:
http://www.outlierdeveloper.com/strategies-for-content-consumption/

Let me know what you think of the article. Thanks to Cory for letting me write it!

8/20/2015

Should I Hire A Mechanic?

Wait, what?! How in the world is answering a question about fixing your car in any way, shape, or form related to making money as a software engineer? Bear with me. I'll get there. As a quick answer to the question though, I got inspired to write this because I had to replace the blower fan in one of my cars. Part cost $80. Labor was free because I provided it.

The reason I'm including this on my blog actually relates more to scarcity vs. abundance mindset than anything else. See, I know I'm currently in a position where the scarcity mindset is dictating at least some of my actions. Since I'm a salaried employee (or, as John Sonmez would put it I only have one client) I am not currently earning income doing "other things." This means that instead of hiring a mechanic at $60 an hour, give or take, it's a better ROI for me to actually do the repair work myself. Until such time as I'm actively earning at least $60 an hour for anything I do - it makes sense for me personally to repair the car myself - at least when I can do so easily.

So, for me right now the calculation is pretty easy. Assuming (as a best guess) it would have cost $300 parts and labor to repair the blower motor in my car, and also knowing I spent $80 on parts and then the time for installing the part, I can figure out how much value I got out of my time. $220 saved, 2 hours used up. So, effectively my hourly rate during this time was $110 per hour. Until such time as I have a "side gig" or additional client where I can earn more than $110 per hour (yes, this is entirely possible and absolutely a goal of mine) it still makes sense for me to fix my own car. And while this example has practical application since I just did this car fixing today - it also applies metaphorically, too. Before you decide to do anything related to your checking account balance or slapping a charge on your credit card - decide if it's worth it to seek a financial alternative.

Clogged toilet? Should you call a plumber or go buy the right kind of auger to clear it? Ultimately that's your call, but if you go buy the auger then you have an auger the next time you need one. Unless of course you're happy to lay out a hundred bucks because your kid flushed his toy <thing> down the toilet.

Get a barber/stylist to cut your hair or do it at home? Again, it depends on how much value you put on your haircut and how good you are at cutting your own hair.

Stop working, or hire a nanny? There's more than economic impact to consider on this one, the social and psychological implications have a non-monetary benefit that's pretty hard to put a dollar value on. But if you look at it simply from an opportunity cost standpoint, if your ONLY using dollars to measure what you should do, then hiring a nanny is a better choice if you're making big bucks at work. Again, I'm not suggesting everyone in the world should just drop their kid with a nanny and go get a job. I'm just saying that if you think of it in terms of financial net gain, all other variables being a non-issue, you have to weigh the cost of doing a thing with the revenue you're losing by doing it yourself instead of having someone else do it.

Every service in the world has an opportunity cost. If you're installing a blower fan in your car, you're not working on an app, or a blog, or a bug-fix, or an open source project. Nobody but you can decide what the most valuable way to spend money is for you. Just remember the next time you're considering rolling up your sleeves to do it yourself, make sure it's really the right way to spend that time doing it. Otherwise, hire an expert and go spend time doing expert things you really love doing.

8/13/2015

How Do I Win?

Do you know how to expand your pie?
Soft Skills Quiz: Week 3. The statement made as item 3 on the quiz: I feel confident in my ability to interview for a job, ask for a raise, and negotiate a job offer. That last part is really kind of asking, how do you come out ahead or "win" when talking to a manager? I'm going to concentrate on the negotiations part of this question, because it's worth a whole post by itself. The best way to make this happen is to also ensure the manager wins, too. 

There's several different ways people define winning. In the case of this blog, what I mean by winning has a pretty simple definition - winning means more money in your wallet. However, in order for you to win, you have to make sure that your current employer (or potential new employer) also knows they win by hiring you (or giving you a raise).

In management school, the concept of "expanding the pie" is one of the core things that we learn when talking about negotiations. While a somewhat silly sounding phrase, it carries with it a fair bit of good knowledge. When you talk in real dollars, expanding the pie simply means thinking about your compensation in terms of things other than salary. If your boss/new employer has reached a cap in terms of salary they can offer, perhaps instead they can offer you more vacation time, or find a way to reduce your portion of benefits you have to cover. Maybe you can convince the person you're talking to that working from home would have great benefit for both parties. What I mean by this is, if you work from home, maybe you can promise to your new employer or current boss that you'll work during half of the time you would have spent commuting. You get more time at home. And your boss gets more work hours out of you.

Another term for this comes from a book I recommend frequently, The 7 Habits of Highly Effective People. The habit I'm referring to is to "Think Win Win." Instead of playing a zero sum game where you come out ahead and the manager loses, or you lose and the manager comes out ahead, find ways for both of you to benefit from the end result. And don't just think in terms of money. Think of growth opportunity, title, team, department, telecommuting, vacation time, and many other things that don't have fiscal value, but definitely have tangible value.

Unfortunately, sometimes you'll find yourself in a position where the person you're talking to doesn't understand how to play the game where both people win. If you find this to be your situation, you need to be sure you're bringing to the table a BATNA. Yep, another one of those silly business school terms. BATNA is just an acronym for Best Alternative to a Negotiated Agreement. What this really means, more than anything, is that you have to have the willingness, and ability, to walk away. If you're negotiating salary with a new potential employer, your BATNA, at the very least, is your collection of current salary and benefits. If the new employer cannot match what you're currently earning, unless the non-monetary benefits of getting hired at the new place out-weigh the monetary ones, you can walk away. In my experience, if you tell a hiring manager "I'm sorry, but that's not good enough" they're going to try just a little harder to up the ante. Which works out in your favor.

Another important and often overlooked aspect of negotiations with a job offer is to set clear expectations right at the beginning, even when the interview is starting out. You want to be as transparent as possible going into the interview process about what you're expecting the manager to accomplish on your behalf in order to make it so you're willing to shift into a new career.  If you feel like working the new job is worth $100 thousand a year, and you're worth it - say so. If you don't, you may go through the whole process to find out that what they're hiring for doesn't come anywhere close to your expectation. It's a waste of your time and theirs if your expectations don't line up to begin with. So be clear about them - but be careful, too. If you say "I think someone in this job should earn $100 thousand a year" - guess what, they're going to offer you $100 thousand. Instead, something like "I've done market research that suggests people in this position earn between $85 thousand and $135 thousand. Does that match your expectations?" Now you've given yourself a pretty good field to play in, so when the job offer comes in a little too low you can talk about moving it towards the upper end of that range.

There's all kinds of literature out there about negotiation tactics and how to make sure the negotiations go as well as possible in your favor. While my tips about BATNA and expanding the pie offer a good glimpse into how negotiations work, I'd strongly encourage you to scour the internet (or a bookstore/library) for resources on the subject. It's a complex and multi-faceted skill, and one that plenty of research has gone into perfecting. That way you can win, too.

8/06/2015

How Do I Play Nicely With Others?

Soft Skills Quiz: Week 2. The statement made as item 2 on the quiz: I always seem to get along with my co-workers and clients, even when we don’t agree. On the page John wrote, he suggested a book How to Win Friends & Influence People by Dale Carnegie. This is great - I think it's important to have a lifeline manual about how to talk to other people. I think it's especially important to focus on talking to people that you generally disagree with or - even worse - don't like at all. However, if you don't really have time to read an entire book right now (actually - I'm going to point to one more) - I'll provide a few of the highlights that work really well for me, when I'm doing a good job being cognizant of them.

  1. Practice active listening. Do it ALL the time. I mean, always. Practice with your wife, your child, your dog (OK, maybe not the dog) and anyone else you encounter. It's especially important to practice active listening in very high stress situations, but it's hard to remember to do this when you're adrenaline gland is pumping. So do it even when you're totally "zen". 
    • Guy dinged the fender of your brand new car? Listen to him, maybe he was up all night with a teething baby. Give him a break, that's what insurance is for after all.
    • Been up all night with a teething baby? Listen to your wife, she might open up to you about how frustrated she is to be losing sleep too.
    • OK, so here's one that's not related to my home life - the product owner changed the requirement/acceptance criteria you just promoted to production? Again? For the third time? Listen to the product owner, there's a better than average chance they can point to market research that explains why the feature works better the new way. They're probably frustrated too, because they've had to write new acceptance criteria. Empathize with that frustration, then get to work.
  2. #1 is a dictionary definition of one of the core concepts in Stephen Covey's The 7 Habits of Highly Effective People (oh, great, more reading homework!), One of the tenets of the book - Habit 5 - states "Seek first to understand, then to be understood." If you don't take the time to get to know the perspective of the person you're dealing with, you'll have no ability whatsoever to influence that perspective to more closely align with yours.
  3. Watch your body language, and theirs. Pause and imagine what you look like if you have a mirror in front of you. Are your arms crossed, is your face terse? You're likely coming off as combative and unwavering, and it's going to stop people from wanting to talk to you. Consciously work to put your hands in a more relaxed position. And if you really want someone to feel included in your conversation, purposely point your feet at them. And make eye contact. There's plenty of research material that proves body language has WAY more pertinence than written or spoken language. So use it to your advantage, and watch what other people's bodies are telling you even if they don't realize it.
  4. Which, of course - brings me to my next point. Smile, genuinely. Smiles are contagious and you can hear them in someone's voice, even if you can't see the person. If you actively smile during a conversation your positive attitude will rub off on other people too.
  5. Deal with toxic coworkers as soon as you possibly can. Seriously, they're not only going to bring you down, they're a drain on the entire team. It's one thing to have different perspectives from other people and to set them aside in the name of your team's mission. It's another thing entirely if someone is actively reducing your capability to pursue that mission. If you're the manager, correct or cut ties. If you're not the manager- get the manager to do so. Use all of these tools to help the manager understand your concerns. Otherwise your next active listening might be with a recruiter because things will continue to deteriorate if the situation doesn't resolve quickly. Toxic coworkers come in many flavors. Know how to spot them and know how to talk to management about them.
I'm sure I have other little things I do that keep the dysfunctional relationships at bay, in the office. I've had plenty of coworkers who really got on my nerves for one reason or another - but at the end of the day it's not my job to like them. It's my job to maximize value and productivity for my company and my team. Communication differences and personal preferences aside, the best interest of the company comes first. As long as they're not actively pursuing a negative path, professionalism has to win.

7/30/2015

Guest Blog Post - neteffects

I'm proud to suggest the business neteffects puts into the IT industry 
For my blog post this week, I've been asked to be a guest blogger here: http://bit.ly/netfxgbrezrefact

Please support neteffects by checking out this post. I hope you all enjoy it!

After this post went public, I shared it with my family via email. My brother - an outstanding software engineer - had some counterpoints to make. I asked if I could share them here, and since he agreed I'm adding them below. I left them more or less un-edited, so keep that in mind as you read through our thread back and forth to one another. His words I've put in blue, since that's his favorite color. I've put mine in green to keep with the theme/branding of the blog.
You know I love what I do. You know I care deeply about it. You may or may not know I love sharing what I do and my knowledge about it with others who come seeking it (that's why I tutored for 3 years at WashU).

The fact that I don't want to share all of that with the whole world arbitrarily shouldn't affect your opinion of me as a potential employer. If I were looking for a job, I would definitely try to build up a network on LinkedIn, but as for the rest, it's not for me. I really don't think that should matter, and if it does, the world is more broken than I thought.

I also don't know if that mindset is quite as ubiquitous as you seem to (though I also don't know it isn't), and I certainly hope it isn't. Admittedly my experience with the hiring process is antiquated. The popularity of social media (and by extension other forms of "online presence") shouldn't be understated, but I do think the world's obsession with it is somewhat temporary, and I don't know if it extends quite as far to hiring directors as you do. Maybe I'm just a dinosaur by some standards, but if so, I'm happy in the Jurassic (when all the best dinosaurs existed), and I plan to stay here as long as possible.

For what it's worth, I know that the "it's not who you are, it's who you know" concept has existed since long before the internet, and despite the fact that I hate that about the world, I also know it's not changing anytime soon. And yes, strong, unpopular opinions like the one in this e-mail are the reason I don't share them with the world.

You might be surprised at just how "popular" your "unpopular" opinion is. Just because what I write about works for me (and works well) doesn't mean it works for everyone. Yes, traditional methods of job searching are still valid, they just may not return results as quickly as you might hope (I don't know - but I do know that what I've done works quickly almost every time). However, even if you decide to completely ignore all of the internet stuff that's out there - don't forget the most important part. Strong personal recommendations. I'd refer you to ANY of my previous employers, because I know your work. That trumps anything online, hands down. (I may not have made that point strongly enough on the blog post). Once you have the trust of your manager, if you hand that manager a resume and say "Hey, hire this guy/gal" - they're going to have a very hard time ignoring it. Doesn't matter what else they have or have not made available to the world.

Thanks for the constructive feedback.

Yeah, especially within our field, a lot of us are pretty stuck in our ways. So it's certainly possible my opinion is more popular (at least for us) than I think it is. I do definitely concede that "my way" might not return results as quickly. I have no problem building rapport with the people with whom I work most closely. My manager has explicitly told me he would give me a good recommendation if I used him as a reference. I think that's probably true of anyone in my department.

7/25/2015

Now With More Subscriptions!

OK, I really could have come up with a better title, but I'm corny and wanted to just put this out there for everyone. If you're more interested in getting my blog via email instead of on the interwebs, I've got a sign up page for you to use. If not - same time, same place, next week.

7/23/2015

What's My Career Goal?

As many of you saw a couple of weeks ago I answered a bunch of questions that John Sonmez posted on his blog. Unless I have interruptions from other ideas I figured I would use his quiz as inspiration for what to write about.
My answer to his first question: I have a clearly defined goal for my career.

I'm the proud owner of a professional mission statement. You too can own one. There's several different books out there that talk about how to do so - however the way they describe it in Team Geek really spoke to me. I'd highly encourage you to come up with one yourself. Otherwise, how do you know where to go next? Your mission statement does not have to be permanent. But I encourage you to come up with one that sticks around for a while. It should also be something that isn't ever really "done". Otherwise you might allow yourself to become complacent.

Here's my mission statement for my career:

Through servant leadership elevate to a higher standard of quality and productivity all professionals I come into contact with.

It's short, and that is the point. I can reread it (and refactor it) very quickly, so that it sticks to the top of my brain. However, just because it is short doesn't mean that it is low impact. Here's what I mean.

Through Servant Leadership elevate: This is the ongoing point in which I remind myself that the most important success factor in my career depends not at all on me winning. It is my job and passion to make sure everyone I work with wins. Anything I can do to help eliminate roadblocks and propel other people to the top of their game, I will do. The main importance behind this is that as I elevate others higher, my own career flourishes along the way.

Higher standard of quality and productivity This part, while stated generically, applies very specifically to my career in software engineering. There's a plethora of knowledge in our industry about coding best practices, clean coding, maintainable code, testability, and so on. However, just because there's brilliant expertise out there doesn't always mean people instinctively follow it by habit. By introducing the tenets of measurability, continuous improvement, and static code analysis (among others) I help junior developers and fellow senior developers take significant pride in their output. Software engineering has many similarities to artistic crafts, and I expect my teams to drive to match the likes of the most respected masters. Think Michelangelo and Picasso, but in the world of software. There's generally debate as to which "masters" to emulate. However, the point is to ensure that we all know our position in the debate, so that our code intelligently reflects our position on mastery.

All professionals I come into contact with: To put it bluntly, I don't think enough software engineers care enough about people who don't write code for a living (or for fun). Yes, my first priority lies in the quality and output of my fellow engineering team. However, if we're amazingly awesome engineers and the people writing the backlog have no idea how to create value, then we're going to be really efficient at writing software that nobody uses. If the client facing expertise in the company cannot rely upon the engineering team to help them set mission and vision, I strongly feel that the team/company as a whole is dysfunctional. Sure, I consider myself a geek and hang out around my geek buddies way more than anyone else. But I understand that helping anyone I can, geek or not, really drives home my mission.

As I've been writing this, I've been thinking about the fact that I think my mission statement is missing a key aspect - humility. I like to surround myself with people that are way smarter than I am, and also way better at their jobs than I ever could be. So - I need to find some way to incorporate the fact that it's my mission to help make everyone else feel stronger in their careers, but to do so in a way that I don't come across as an egomaniacal prick. If anyone has suggestions for how to start incorporating better humility into my day-to-day, I'm all ears. I'm thinking maybe I need to add something like "through encouragement and companionship" to the end, to make it more clear to myself that it's not necessarily always mentoring I'm doing. Most of the time, in fact, I'll end up being mentored. Stay tuned for my answer to the next question about getting along with my peers - because I think it's well related to my point here.

What do you think? Can we all make mission statements that are both powerful and humble at the same time? Leave me a note if you want in the comments, I'd love to hear your thoughts too.

7/16/2015

How Do I Get My Manager To Support My Idea?

Money talks. At the end of the day, when you commute home (or walk out to your living room from your home office) money is most certainly one of the main reasons you spent all or part of your day working. Granted, many of us absolutely love the work that we do. We hardly even call it work, because we're so passionate about doing it all the time. But, to keep the lights on at home and the kids fed, we have to get paid doing it.  Scale that up by 5 or 10 people. Now you're talking about a small business or a team at a large business. If you want to get something done at work, talk about money. Specifically, you need to talk to your manager about return on investment. Here's what I mean.

Let's assume for simplicity's sake that your company only does one thing to earn a profit - let's assume that the company has come up with an amazing algorithm to read the stocks/bonds/commodities market to ensure that no matter what, any money put into the algorithm will net 10% year-over-year. This means if the company puts $1000 into the algorithm at the beginning of the year, at the end of the year the company will have $1100 coming out. Again, for the sake of simplicity I'm making the argument that the company you work for can predict the value of all its investments making a 10% return. In reality, calculating year-over-year returns is a bit more tricky, but it's also mostly not necessary to know the exact ROI your company expects for getting your manager to do something you want/need to do.

Now let's assume (again for the sake of simplicity) you want to buy a one year license of OMG This Is The Best IDE Ever Made!!! Assuming that you're talking a fairly standard licensing fee, let's say that one year for this IDE costs $250 a seat. Let's also say you want to do this for yourself and 4 people. Wait, that's $1000 (see what I did there?!) So, now you have to convince your company with the slogan "We make 10% on all of our investments" that spending $1000 on an IDE will be worth MORE than $1100 to the company after one year. How can you do this? The easiest way is to determine how much added productivity you'll gain on your team by using it. Let's also assume that your 4 person team averages $50 per hour. That's $200 an hour spent on developer time. In order to be worth more than $1100 to your company, the IDE has to be able to obviously save 6 hours of development time, per year, to be worth it to your company. 6 hours, $200 per hour, $1200 ROI. If you can prove to your boss that this IDE will in fact, on average, give you 6 hours of development time back per developer - then the ROI of getting the IDE instead of just investing the money is worth $100 more to the company.

While I intentionally reduced all of the made up examples for simplicity sake, it really isn't all that much more complex in the working setting. All you have to do is figure out how much it's going to cost to do whatever it is you want to do, and then also figure out how much it will save on expenses or earn extra in doing so. If you can prove your idea for a book/IDE/training/feature can genuinely surpass the rest of the company for ROI, in real dollar value, then you're highly unlikely to see much of an argument from your boss.  After all, the point of running a company is bottom line, at the end of the day.

If you want some help coming up with ways to determine ROI for something, let me know. I'd love to brainstorm on the less than obvious ROI values on things that it's not quite so evident, so that you and your company could both benefit from them.

7/09/2015

Simple Programmer Soft Skills Quiz - My Answers

Questions extracted from The Simple Programmer Soft Skills Quiz

I've highlighted in red those questions that I didn't answer "yes" to when I read the quiz to myself.
  1. I have a clearly defined goal for my career.
    • I call this a professional mission statement. Here's mine: 
      • Through servant leadership elevate to a higher standard of quality and productivity all professionals I come into contact with.
  2. I always seem to get along with my co-workersand clients, even when we don’t agree.
    • I've been called "diplomatic" in the past. I think inter-relatedness is one of the most important things we have in our careers on teams.
  3. I feel confident in my ability to interviewfor a job, ask for a raise, and negotiate a job offer.
    • I've gotten several raises. I've nailed many job interviews. And I've always turned down the first offer when it's not good enough.
  4. I act like a professional instead of an amateur.
    • I always prepare well stated communications that are succinct and courteous
  5. I’m not religious about technology. I pick the best tool for the job, not the one I like the most.
  6. I’ve made an active choice to be where I am. I didn’t just take the first job or opportunity that presented itself to me.
    • I've turned down interviews and job offers that didn't fit me. And I'm proud of doing so.
  7. I have a clearly defined specialty that differentiates me.
    • I'm a programmer that knows how to talk about ROI, EBITDA, Diminishing Returns, Balance Sheets, and organizational behavior. And I don't work for an accounting software company. I'd say that's pretty niched down, but I'm always looking for ways to tighten it further.
  8. I have my own personal brand.
    • (Looks at the top of the screen)... I have a branded website which...
  9. I have created my own blog and post regularly.
    • ... Happens to be a blog I post to at minimum once a week
  10. I’m not afraid to look like an idiot.
    • I've been down-voted on StackOverflow.com. And I'm sure that's not the only time I've ever been ridiculously, blatantly wrong.
  11. I’m constantly learning new things and expanding my skills.
    • I triple majored. Learning is in my blood.
  12. I don’t need a teacher, I know how to teach myself.
    • I like getting my hands dirty and figuring out how to get stuff to do what I need it to do. Sometimes that stuff is mechanical. Other times it's humans interacting with humans. but I'm always working on it.
  13. I’m sharing what I learn with others and mentoring them.
    • I host brown bag lunches at my office once a week. It's fun
  14. I am seeking out the help of mentors who can coach me or give me valuable insights from their experience.
  15. I’m teachable. When I’m wrong I admit it and seek to improve rather than justify my actions.
    • I like to surround myself with people smarter than I am. And I like them to show me when I have growing to do.
  16. I know how to focus on the task at hand and how to avoid distractions.
    • I just re-started using Pomodoro, but I've never had an issue putting in my headphones and telling people to leave me alone. I shut off my email, turn off my IM, etc.
  17. I accomplish what needs to be done before it needs to be done. I don’t procrastinate.
    • I'm not great at taking out the trash at home. Otherwise, I get things done before people even realize they need doing.
  18. I manage my time effectively. I use a daily and weekly planning system.
    • Working on it, but I'm not really great at this yet.
  19. I’ve developed regular good habits that keep me going, even when I’m not motivated.
    • Really this is more about what I don't do. I don't watch hours of TV. I don't play video games. I do have a routine at night that I (generally) stick to.
  20. I take action and make decisions instead of always second guessing myself.
    • I started this blog. I always follow my instincts. And I'm not always right about things.
  21. I understand how markets work and economies function.
    • Ask me to talk to you about economies of scale, the free rider problem, and the invisible hand some time.
  22. I’ve educated myself on various investment choices and understand how to make my money work for me.
    • 401K - Yep
    • IRA - Yep
    • Free standing investments - Yep
    • Diversification - Yep
  23. I have a definite retirement plan that does not rely on luck.
    • See above
  24. I am out of debt or I am on a clear path to get out of debt in a short timeframe.
    • Consumer debt is a 4 letter word in my house.
  25. I understand the basics of good nutrition and health.
    • Understand, yes, absolutely. Less than a decade ago I was in amazingly good health. I don't always follow through now, though... not really.
  26. I have some sort of a regular exercise routine that I stick to each week.
    • I have a plan to start doing this again, and have moved in the direction of doing so. However, it's not habitual yet
  27. I have a healthy and planned diet that I mostly stick to.
    • See my answer that pretty much matches above, but with my diet
  28. I have clear fitness and health goals and know how to achieve them.
    • I'm slightly (but not dangerously) overweight - and I know what foods I have to eat and what exercises to begin to reverse the trend. I've been healthy in the past, and know how to get back there
  29. I understand the connection between my mind and my body and how I can use my mind to make a positive impact on my life.
    • I've fought significant depression in the past, and won. I know how important physical and emotional empowerment are in every aspect of life.
  30. I am empowered. I believe that I control my life through the decisions I make, not the circumstances that fate throws at me.
    • Actually, this one threw me off. I'm a devoted Christian that firmly believes I have a higher purpose as a servant leader with my peers and my community. I don't believe in predestination, but I do believe in God's will.
  31. I have the right mental attitude and I believe in myself and my ability to achieve anything I set my mind to.
    • I regularly succeed. I regularly fail. And I always learn.
  32. I’m not afraid of failure. I embrace failure because I know it leads me to success.
    • See above
  33. I master my emotions; my emotions don’t master me.
So, what do you all think? Leave me a comment to let me know if you think I answered this quiz honestly. I know that these kinds of things are critical for a career to thrive - so I want to make sure I'm being accountable for them.


7/02/2015

Are You Independent?

We're lucky enough to see this out on our front lawn.
People love legally blowing stuff up around my house.
With the US National Holiday for Independence just around the corner, I couldn't help but thinking about what independence really means.  I like the way that Steven Covey defines it in The 7 Habits of Highly Effective People, and even appreciate the fact that he uses the term interdependence as the next step towards high effectiveness maturity. However, the definition he builds doesn't really bring up the fact that many different aspects of our lives can simultaneously be on the the dependence->independence->interdependence maturity chain. I'll use my life as an example, and then hopefully get some feedback from everyone if they agree my with my introspection, and also see if anyone feels they'd like to share.

In my home life, my wife and I are interdependent with one another. I rely on her to take care of the beautiful family we have, and she relies on me to provide us with financial security (and to do the occasional spider squashing). Granted, I've reduced down our interdependence on one another to a very basic level with this example - but as a husband and wife we've reached the interdependence stage. That brings me to my job.

Right now I am dependent on my employer for having a paycheck. Don't get me wrong, it's a really good paycheck and I have amazing health and fringe benefits. But they're not mine. I didn't create the company I work for, and at the end of the day, even though their mission statement and mine line up pretty nicely - I'm still dependent on them for financial stability. Until such time as my investments and alternative revenue streams can replace my paycheck, I'm not independent of having an employer.

So, this is what I mean when I say that Dr. Covey missed something when he talked about this effectiveness maturity model. Many different aspects of our lives could be evaluated based on our maturity towards interdependence, and along the way we talk about independence. So, on Independence Day remember what that really means. It means we're free to take the opportunity to stand on our own two feet and do something. We can all work on becoming interdependent entrepreneurs in control of our own financial destinies. So let's get to work.

6/25/2015

How Do We Protect Quality?

By Cosmocatalano (Own work) [CC0], via Wikimedia Commons
Wikipedia does a pretty decent job of describing the technical details and constraints that define the project management triangle (see the image to the left) but while a decent textbook definition helps explain what this means, working in software and experiencing it firsthand makes it a bit more potent. In my current project we're pushing a significant amount of scope very quickly. We're also doing so with a staff augmented by a third party contracting company, but don't have a large enough team fully engaged to deliver both features and quality - It's getting lots of features out fast, and comparatively cheap, but the quality has some obvious hurdles for us to get past. I'd like to focus on our strategy for addressing them here. We have some catch-up work to do, and since we're starting to focus on it I think it's a good thing for me to write about.

Technical Debt

Application Logs

In order to ensure that our application performs well, we need to rely on application logging statements.  As of right now the logging framework we have in place can do a pretty good job of capturing system events and error messages, but we have to ensure that all of our end points and database access properly make use of the logging in the first place.  Once we have the log messages, we're collecting them all using an instance of LogStash, and have them on a dashboard rotating above our heads.

Static Code Analysis

We have a SonarQube instance that runs static code analysis over our source code, and also aggregates some of the other quality metrics that we collect. It shows us the most critical areas of technical debt that we need to address (and believe me, there are several) and also shows the coverage and completion rate of our tests. Really, it's my goal right now to make SonarQube our central hub for capturing all of our testing metrics, because I think it's easier to remember to look in one place than to have to do so in many.

Feature Quality

The Testing Pyramid

I'm not going to spend a significant amount of time explaining what the testing pyramid is, this article probably does a way better job anyway. Suffice it to say that we're stuck with an ice cream cone, and summer is heating up quickly, it's going to melt.

Failing Tests

Right now, even though we do have some test coverage generated by a suite of integration tests, one of the biggest things we need to address and eliminate is the team's willingness to check in broken tests. We have some tests failing, and some tests that just won't even run due to errors in the test code. Our analysis tool doesn't have "100%" as the success rate of our tests. Without having assurance that all of our tests succeed, there's really no reason to be writing test cases in the first place.

Application Performance

Operational Monitoring

We're using a commercial tool to help us monitor application state, specifically it helps us watch things like response times and apdex score. In order to ensure that all of our other forms of testing are in fact improving our application quality, this tool will really be the go-to for showing how things are going in the wild. Without a tool like this one we'd really lose the "Ops" part of "DevOps" in our culture, because this shows us where we need to focus our attention the most critically. All of the other developer testing we're doing helps us to greatly improve the chances that our operational runtime will be successful. But when it isn't, we need the right tool in place to show us where to look first.

Performance, Load, and Stress Testing

Application performance testing is one of the most severe gaps in the software development process right now where we are. With all of the other quality checks in place that we have, one place that we just recently focused our attention is overall user satisfaction with response time. We recently (as in, last week) have a jMeter library set up that runs automatically and collects statistics about response times for our application. We'll keep using jMeter to push our application as best we can, to weed out bottlenecks and eliminate them as quickly as possible.

6/20/2015

New Look

I've applied a new visual style to the blog, and came up with a logo! I think it's better than before, but let me know what you think.

6/18/2015

What's The Difference Between A Boss And a Leader?

BossVsLeader.jpg

In order to capture the essence of how I mentally differentiate between bosses and leaders, I decided to get a little help from Trimble SketchUp and Canva to craft a visual metaphor of how I see bosses and leaders working differently. By the end of this post you should have a decent idea of the kind of approach you want to take in your career long term, but also the kind of approach your manager/supervisor/director/president takes within the organization as well. 
 As a caveat before I begin talking about the two ways people create direction in an organization, I realize some people are happy either being the figures the boss sends across the bridge, or being the ones following the leader across the bridge. I have observed over time that most people seem happier and more productive when the concept presented in the second graphic matches their job, but on occasion the concept in the first graphic can work - if you have the right kind of boss pointing the way. Usually for the bossy one to work there's actually a leader who says "boss is right, follow me" and the boss would have been leading the way in the past, but preferred to delegate instead because more than one team now depends on said boss. 

 This graphic includes several visual elements to represent some of the challenges we face at work every day. Here's a breakdown of what I see each one meaning, and how a boss manages differently than a leader.

 Team
At the end of the day, the team is the group of people that get the work done.  Whether they bring back the prize at the behest of their boss or decide together that the prize is worth seeking, the team ultimately ends up doing the work. Most bosses (the bad ones at least) decide that they own their team, not that they are part of their team. The team is there to go get the trophy for the boss, and if a member of the team doesn’t want to go get the trophy they usually have to find another team. For bad bosses, teams are just tools that can be broken and thrown away. Most leaders (even if they lead from within a management position) are part of the team. They work together with the teammates to decide which prize to go after. And they decide with the team if they prize chosen has become too difficult to attain. When they do bring a trophy home, it goes in the trophy case that the team shares, together. And if any one member of the team starts to get weak, the rest of the team shores up to help out.

 Large Desk: 
This is the place where the boss makes all the decisions about where his team goes. When the fire fight starts he will also tend to use it as a shield, because after all his team is expendable, but he is not. Also, the leader has no large desk. He assumes that the best course is to convince the army at the other end to stand down, but will also take a bullet if a fire fight starts.

 Chasm/Canyon: 
We face uncertainty at work every day. This uncertainty separates us from our goal (the trophy) and makes the obstacles in our way (the army) all the more daunting. A boss will say "go across the canyon and return my prize. If you fail i can just find a different team that is better anyway." A leader will say, "We all agreed that the prize on the other side of the canyon is worth going after. Let's go together across to get it and share it. I'll protect you the best I know how as we cross."

 Bridge: 
This represents the chosen path through uncertainty. When a boss chooses a path and it's the wrong one, he usually blames the incompetence of the team for failing his vision. When a leader suggests the path the team works together to forge it. If it turns out incorrect they work together to decide on which path to try next and forge it together.

 Armed Guards: 
The armed guards represent the obstacles, both known and unknown, that hinder our progress towards achieving a goal. The boss tends to ignore the risk for casualties, after all he can just send in more people until the job gets done. The leader has no desire for any casualties, because the leader would insist on being the first. Nobody on the team is expendable, and everyone works together to find the best way to deal with the armed guards. With a good leader-headed team, usually the goal is reached without bullets flying. With a boss's team, the boss might get impatient and detrimentally impact any chance the team had to handle non-hostile negotiating.

 Trophy: 
The prize! The boss wants this for a trophy case. The team wants it because they know it is a prize worth sharing together. The team can decide together if they fight for the wrong prize and seek another instead. The boss likely can't be as easily persuaded. After all, the boss made the choice to go after the prize. Why challenge the boss' ego by thinking they are wrong?

 So, where’s the Manager?
Notice nowhere on the diagram do you see the text Manager/Supervisor/Director/President. Usually speaking, a manager can be both a boss and a leader.  Even the best managers that have all of the right qualities of a leader sometimes need to put on their boss suit and tie when it comes time to make the really hard calls. If a manager does have several teams that each have their own leader, and one team struggles to bring in prizes as well as the other, sometimes the manager has to decide whether it's time to reorganize teams, or to reduce the number of employees on the weaker team in the name of operational efficiency.  For a good manager, when teams don’t deliver, their first step is to find out why delivery isn’t happening.  For a bad manager, usually the answer is to just lay blame and find ways to doc pay, or to outright terminate people. Don’t get me wrong - if a good manager sees someone that constantly draws down the entire team, it’s up to that manager to make the hard call and cut the apron strings.

 My experience with management, both in large companies and small ones, tells me that the best managers have a well balanced blend of boss and leader in their repertoire.  At times, they have to have the confidence to say “Go this way, and you’ll have to trust me right now because I know you don’t have all of the data that I do. It’s the right way to go, but unfortunately I’m not in the position to go with you.” Hopefully, most of the time they have used proven leadership so that when the time comes that they have to direct instead of lead, people trust that direction. More often than not the best managers act with the concept of leadership in mind. But they have the authority to be the boss on occasion, and hopefully that’s a good thing.

6/11/2015

How do I Deal With Major Mistakes?

Every professional, engineer or not, feels extremely distraught when they mess up. However, while some professions have the luxury of only having their failure visible at a limited level of exposure, most of the time software engineers that mess up tend to get a large amount of negative attention very quickly. The last time I screwed up majorly, a Vice President at my organization (a really big one) noticed. And he wasn't happy about it. My boss wasn't happy about it. My team wasn't happy about it. I REALLY wasn't happy about it. Really, there was just lots of unhappy going around, because it was an expensive blooper that cost a good bit of additional development and operational overhead to correct. While I can't put a literal dollar value on what it cost my company, I can estimate the number was probably somewhere in the $10K (or more) range, mostly as lost opportunity cost or developer hours spent fixing it. This wasn't my first screw up, but (as of now) it's certainly my most expensive one. And yet, when the proverbial "pile" started growing, I kept my cool. Getting worked up and angry at myself could have made an already bad situation much worse - so instead I just hunkered down and figured out how to fix it.

My biggest mistake in this situation was in trusting a deployment pipeline to give us the right answer about the deployment of the application we were working on.  A critical bug was discovered in production, and we had assumed we fixed all of the edge cases that caused the bug and deployed confidently on this assumption. It turns out there were more edge cases. Lots of them. And our deployment pipeline had no knowledge of them, so it happened again. After we confidently said it was fixed. Ouch.

So, several things had to happen after my major mishap. First, and foremost, though - I took ownership of it. Several people were either directly or indirectly involved in the writing of this code and the decision to deploy it, but at the end of the day I had to have the ultimate final say-so that we'd gotten the solution good enough to face our (internal) customers, and I signed off on the solution. So, I found my boss and told him exactly what happened, as honestly as I could, about how this code could get into production in a still broken state. In order to maintain respect within my team and organization, taking responsibility for the error was the best way to show that my professional integrity, though sullied, was far from failing completely.

Next, we worked as efficiently as we possibly could to get the issue fixed. Thankfully it was a job that ran once a month, so between runs we had a little bit of time to clean the egg off of my face.

After that, we went through the process that lead to the broken deployment.  We laid out all of the decision points that could have lead to the failure, and determined where I could make some changes in my own methods for reviewing software to help prevent errors like this in the future. What this basically amounted to was learning where the deployment pipeline wasn't reliable, and finding out how to deal with this in any further deployment - with a manual checklist.

At the end of it all, once I'd cleaned the egg off of my face (with my team's help) and grudgingly accepted the major ding in my quarterly goals review, the most important thing of all was to review the bad time as a learning experience.


Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience? - Thomas John Watson Sr. - First CEO at IBM1

It's possible to learn from success - at least as far as knowing the things that you can repeat to keep being successful. But the kind of learning that you gain from a failure is akin to the kind of learning you do when you put your hand on the hot stove for the very first time. It stays seared into long-term memory, and helps to propel greater things. We all need to stand on the shoulders of our past mistakes, knowing that we're strong enough to make different mistakes in the future. At the end of the day, if you work somewhere that you respect, and that has respect for your talent - you'll get the opportunity to prove you can be trusted, and you'll also get the opportunity to prove that sometimes - mistakes are just really expensive training exercises.


  1. If anyone has a source where this quote was captured originally I'm happy to cite it here.  This is just a citation of someone else that re-used it. http://www.inc.com/murray-newlands/30-quotes-to-remember-when-recruiting-for-your-startup.html

6/04/2015

Should Code Have "Come Back to this Later" Comments?

We did this today.

    # HACK: Fix this later, this is awful
  ssh $USERNAME@$TARGET '
    for file in $(grep -rl some-string-we-need-to-replace /some/directory/to/do/work/in)
    do sudo sed -e "s/some-string-we-need-to-replace/the-string-to-replace-it-with/g" -i $file
    done'

I'm not particularly proud of writing code of any kind that has these kinds of statements in it. I tend to repeat the mantra "If we don't have time to do it right, when will we have time to do it over?" in my head somewhat repeatedly. I've even known to say it out loud on occasion. And yet, here I am staring at a bash comment with the big green word HACK in it. I plan on doing the walk of shame later, for now I'm going to explain why I feel like there's a few of important rules to assume when you're writing code at work.
  1. You're never going to come back to code that you write "I need to come back to this later" in the comments. While this may not always hold true, in general if the software "works" as is, you're going to have a very difficult time convincing your boss/customer/whoever that you need to go back and fix it if they don't see anything broken to begin with.
  2. Any time you do write "TODO", "FIXME", "HACK", or your favorite word that is supposed to make you fix it later, you need to make your boss/customer/whoever understand that you do need to take the time to go back and fix it later. This is usually very difficult.
  3. Sometimes real deadlines in the release environment make it so that we have to cut corners and just get something deployed. We don't have time to do it right, right now, because we have a customer waiting for it. Just be ready to do it over when something unexpected happens because of your TODO, and be ready to get a good bit of egg on your face if it does happen in the wild. Be VERY selective about how and when you use TODO statements in your code. Production code with TODO in it doesn't seem like it belongs as production code (to me).
  4. There's an exception where you're doing something like "TODO: Need to make sure to remember that when we're implementing feature AWESOME-1234 that this is the right place to put controller/domain/dao/magic logic." TODO reminders about future new features are OK, most of the time.
We all have to write code we're immediately sickened by when our fingers type it. Hopefully we all find ourselves in roles where we don't have to do it all that frequently. But, it does happen (see: http://www.commitstrip.com/en/2015/05/29/always-stuck-somewhere-in-my-head/) - so we need to be careful about how we exercise our powers of evil getting things done. Otherwise we may end up writing "TODO: Find new customers because the old ones don't trust us any more" - and nobody wants to have to write that.

5/28/2015

Should I Have a Facebook Account?


Facebook Poll Results As Of 6-3-2015
Poll Results As Of 6-3-2015
In order to find out what people think of my question, I put up a poll on Google+. I ditched Facebook some time ago, and thus far I have to say that I find myself with more time for blogging and other productive interests since I don't have one. I also find myself not compulsively checking my phone every 2 minutes to see if <so and so> ate <that really cool designer food stuff>.

All kidding aside, my professional/personal network is pretty solid, and I'm not entirely certain I'd make it any stronger by adding Facebook back into the equation. Since I haven't been on it in a few years, I honestly have no idea what kinds of feed grooming tools and other signal/noise toggling features they've built in to the service to make it more useful for the customers.  I can say that without much doubt, Facebook provides their development staff with all kinds of amazing things: http://www.businessinsider.com/facebook-vs-google-best-employer-2013-11, and I support any company that treats developers like rock stars. However, if I get back onto Facebook I want to maximize it's potential for helping me propel my career, network, and life goals.  Here's the things it has to offer to be worth it for me:

  • More readers on this blog
  • Stuff that I want to read, not just random nonsense that I don't care about
  • Connectivity to people I care about, not to people who I barely know
I really don't know if I can curate a Facebook account well enough to accomplish those things up there. I suppose it's probably possible, but I really want to protect myself from being consumed in it again, I've really enjoyed my Facebook hiatus thus far and I don't want to find myself coming back to this blog in 3 months saying "Well, I quit Facebook, again." Garth Brooks and Michael Jordan can retire more than once, but I'm not sure if it'd do me any good ;).

So, what do you think - honestly? Can Facebook really be a valuable tool, or is it more of a time waster that makes Mark Zuckerberg a ton of money?



JSON Jason