As developers, we love talk of clean code and nice, friendly code bases. We lament if our higher-ups don’t share our vision of a codebase that resembles a sunny day in a grassy meadow with the birds singing in the trees. Who’s right in this situation? Everyone is probably right… and probably wrong.

Before I bore you with yet another “it depends”, let’s think about why there are different viewpoints on this issue. The obvious answer is that many times it’s a matter of context — people in the business might not do a good job of explaining why delivering results is so valuable to the business, and development teams might not do a good job of explaining why having clean, maintainable code is going to help them deliver better and faster results. I don’t think you need a blog post to tell you that.

I had a fascinating conversation over Thanksgiving about why it is that we have these disagreements. Turns out it’s not always just a matter of context, it also has to do with your personality.

There’s an assessment out there called the Strength Deployment Inventory (SDI). You can read about it if you want the details, but the gist of it is that there are 3 primary ways that we are motivated and deal with conflict, and we all have varying degrees of each motivation.

Source: https://totalsdi.com/

• Performance-oriented – you have concern for task accomplishment and organization of resources to achieve results
• People-oriented – you have concern for the protection, growth and welfare of others
• Process-oriented – you have concern for well-thought out approaches, order, individualism, and self-reliance

It’s possible that you have some or all of some of these traits. There’s no right or wrong here, but it’s really important to understand the way people think (and how you think compared to others).

For example, many managers are performance oriented, and that’s part of what draws them to that role. But many developers tend to be process oriented. Herein lies the seeds of conflict, unless we can try and understand where each side is coming from. Going back to my conversation that I was having, my extremely process-oriented brother-in-law said that even though he knew that sometimes he had a tendency to not be focused enough on results, it was very difficult for him to not write clean code or do a “good job”. Perhaps he needs to do a better job of seeing the importance of results, but I don’t think we should quickly dismiss this as a weakness.

It all comes down to what strengths you need on your team. If you’re developing a smartphone app for a startup, results are pretty much all that matters. But if I need to write a billing system, I want my brother-in-law on the team because we will take full advantage his process-oriented strengths and we need his level of rigor in order to ensure that costly bugs aren’t introduced.

This thought process is not often reflected in job listings that list years of experience and knowledge of various frameworks as job requirements. In reality, whether or not you can adequately explain what an Angular directive is probably very insignificant compared to other innate strengths of the candidate. In my mind, the ideal goal should be to find someone that has the specific strengths that you are looking for so that you can take advantage of the things they are naturally great at. Sure, knowledge of frameworks is important, but it’s much easier to teach someone a framework than it is to change the innate strengths and weaknesses of a person.

We should work really hard to become aware of our weaknesses and improve on them, don’t get me wrong. But if you want to harness the true power of a person, find out what their strengths are and cut them loose in an environment where they can take full advantage of those strengths.

These days most every workplace seems to be at least somewhat set up for you to work from home. Most places have a VPN where you can connect from outside the office, and flexible work hours are becoming more prevalent, especially for developers since they tend to spend less time in meetings and sometimes like to work at odd hours.

I am one of those people. I have young kids, which means that I tend to get in a little later than most people and I also leave a little earlier than most people. In order to pull this off and still have time to go to lunch occasionally, I have to work some at home, either at night or on the weekends.

Personally, I like this setup. It allows me to have more flexibility with how I spend my time, and if I need some guaranteed uninterrupted work time, I can get often get it at home. What I didn’t expect is the perception I gave people when I started doing this.

The new face time

It used to be that some workplaces would unfairly judge people by how much “face time” they put in it work (which I think is garbage, but that’s for another post). That seems to have lessened (at least at the places I’ve worked at), but now I have the capability to work pretty much anytime at home.

When I say I work at odd hours, I mean it. I’ve updated work items at 8:30pm, checked in code at 2am, sent emails at 6am, deployed stuff to test environments (which sends notification emails), etc.

The perception this gave people was that I worked all the time! People assumed that I was working 40ish hours a week at the office and then going home and working some more (and sometimes a lot more). This wasn’t true at all (I usually don’t work lots of extra hours), but I had multiple people say that they thought that I worked tons of hours.

What I do with my time is my business, so if I were one of those people who wanted to work 60 hours a week, I’d say that was fine because it’s my time and my choice. But it becomes a problem when my perceived work schedule affects the way people feel about how they spend their time.

The problem is that now other people on the team (particularly those who are new and want to make a good impression) feel like maybe they’re not doing enough if they’re not online doing work at all hours of the day. Maybe they feel like they need to put in more hours in order to be successful or even just fit in. They might start feeling guilty if they don’t log on on Saturday and respond to the email that I sent on Friday night.

This does not lead to a healthy work-life balance. I don’t want people to feel guilty about leaving work at work, or not taking their laptop home on the weekend. I want them to feel good about the time they spend at work as well as the time they spend at home. I want them to know that their hard work is valued, but that they don’t need to work loads of hours in order to be appreciated.

What I’m doing about it

I’m still going to work odd hours. It works really well for me. But in order to not give the wrong impression, I’ve started doing things differently.

• I almost never send emails on the weekend or at night, unless it’s responding to some kind of production issue or something that really needs my attention, or unless I’m sending it to someone who knows me and my work schedule. I especially avoid send emails to large groups of people at odd hours. I might write up an email, but I’ll leave it just leave it sitting there so that I can hit Send on Monday morning.
• If I want to check in code, I’ll commit it locally but not actually push it up to the server until I go into work. (This also saves me from breaking the build on the weekend and then having to fix it when would rather be doing something else.) Of course, you need a distributed source control system like Git to do this (sorry TFS users), but if you’re stuck with TFS, you can achieve this with git-tfs. You really should use Git anyway because it’s awesome, and you get huge benefits for something that’s fairly easy to learn.
• I try not and talk about working at odd hours when lots of other people are around. They might not know why I’m doing it, and it might give the wrong impressions about expectations. Too often it comes across as boasting that I’m in some way better for being willing to give up my free time (when in reality, I’m not giving up any more free time than they are, I just do it at a different hour).

Working at home is great, it can lead to some bad misconceptions and unhealthy team dynamics, so just be cognizant of how people might be interpreting your actions.

I was having a discussion today with some people at work who were reading a book that helps you determine your strengths so that you can take advantage of your strengths and be great at what you do. That led me to think that while knowing my strengths is a good thing, I also want to know my weaknesses.

When I was starting out as a developer, I remember reading up on how to interview well and potential questions that interviewers might ask. One of the potential questions that I saw listed in several articles was, “What are your weaknesses?” That question didn’t really make much sense to me, maybe because I didn’t really know how to answer it (“yeah, my weakness is that I work too hard”), and I didn’t really know what an interviewer might want to get out of it.

I’ve never had anyone ask me that question in an interview (and I don’t think I would ever ask it in an interview myself), but I think the reason that someone might ask that is to see if someone is aware of their own shortcomings and if they’re doing anything about it. So here are some reasons that I try to learn my weaknesses.

Knowing what roles to avoid

We all have things that we are good at and things that we’re not so good at. There are many different roles you can play on a software development team (or any team for that matter). Maybe you really enjoy coding and are really good at it. Maybe you are good at project management and coordinating multiple efforts in order to reach a common goal. Maybe you have strong management skills and can help your team members get better and achieve their career goals. Maybe you are good at helping teams adopt Agile practices. Maybe you’re good at talking to users and business people.

As you read that list, you probably thought of some of those things that you are good at and that you really enjoy doing, and maybe others that don’t get you so excited. This is really really important to remember so that you don’t inadvertently steer your career down the wrong path. The classic example is the developer who was really good at coding and was promoted to management and now can’t take advantage of their strong development skills that got them there in the first place. On the other hand, I know some developers that went into management and thrived there. Either one is fine, but you’ll be happier and more successful if you can stay in a role that emphasizes your strengths.

Knowing what to work on

Some things will come naturally to you, and other things won’t. That doesn’t mean that you should only do things that you’re good at. Most developers naturally are not extremely gifted when it comes to talking to users and business people, but I think this is a very important skill that I think every developer should work hard at. Being able to right good code does you no good if you can’t create systems that will actually solve the right problems.

This is why most meetups that I attend have more to do with QA testing, business analysis, and project management. I’m better at development than I am at all those things, and I like development the best, but I want to be better at the other disciplines because it makes me a more well-rounded developer and allows me to know how to help entire teams instead of just developers (which lines up with my career goals).

We can develop these skills if we work at them, even if they don’t come naturally. But if you don’t take the time to look at what you need to work on, you won’t ever get better.

Knowing how other people might see you

There are two sides to this one. First, I want people to know me for my strengths. There are thousands of .NET developers, agile coaches, project managers, etc. out there. What is going to separate you from the crowd? What you’re great at.

That will get you in the door, but if you stay somewhere long enough, people will find out what you’re weaknesses are. This is fine, but I want to be aware of how people might be viewing me because that might help me understand the way that people act towards me and why they might make various decisions that affect me. If I’m aware of my weaknesses and other people also have discovered those weaknesses, now I can take what they say and understand more about what they are saying and what is causing them to react a certain way. In turn, this teaches me more about myself and what I need to work on in order to get better. (At no point should I ever beat myself up for my weaknesses, this has no constructive value for anyone.)

For example, I am an extrovert, which is a minority in the software development world. This means that I sometimes tend to think out loud, and sometimes I’ll throw ideas around without having really thought them out. I think this sometimes confuses and overwhelms some of my other team members, who were still trying to understand my previous thought which I’ve already moved on from. While this is the way that I tend to process ideas, I’ve realized (based on how other people have reacted) that this isn’t always constructive for others and that I sometimes need to think things through more internally before I verbalize them.

While thinking about your weaknesses isn’t always a whole lot of fun, it will go a long way towards bringing you career success and enjoyment. We could all use a little more of that.

In our fast paced culture, we are constantly looking ahead to the next big thing. We think about some magical someday when things will be better than they are now. Then when we get there we’re still looking ahead to something else.

I’m all for setting goals for the future and reflecting on the past. The danger in all of this is that we might just miss out on the present.

Recently I’ve been trying to live in the moment and be present in the present. I want to enjoy the people and opportunities that I have in front of me right now. I want to actually stop what I’m doing in my busy day and turn around and listen to someone who wants to talk to me. I want to spend less time looking for the next big thing and spend more time taking advantage of what’s in front of me.

You can’t take anything for granted in life because things change too fast. Never again will things be the same as they are right now. A year from now you might be working with different people, friends might move away, and your kids will be a year older. Sometimes it seems like things will always be the same, but nothing lasts forever.

So I find time to enjoy today. I’ve started to go to lunch with people more often because I want to enjoy them as much as I can. I had a great time in college, and I would give a lot to be able to have one day with those people all in the same place again doing the same things, but those days are gone. I hope that I’m saying that same thing about 2012 in a few years, and I don’t want to regret not taking advantage of it while I still had the opportunity.

While it’s wise to study the past and plan for the future, don’t forget to enjoy what you have now. Because you’ll never have another today.

What do you do when you get stuck on something at work? Do you ask for help? Or are you too afraid to bother someone else with your problem?

This is one of my pet peeves. When you’re writing software, gathering requirements, testing, or whatever you are doing, at some point you are going to get stuck on something. You spend a little time trying to figure it out, but you can’t solve the problem.

At this point, many people are afraid to ask for help. I don’t think that it’s because they’re too proud or lazy to do so, they just don’t want to inconvenience me because I “look like I’m busy” or they “don’t want to bother me”.

I may actually be busy and I maybe I even don’t want to be bothered, but if I can spend one minute answering someone’s question and save them 20 minutes of figuring it out (and the headaches that come with it), I’m going to do take the time to do it. Even though it’s an interruption, that time spent helping someone else is a good investment that will pay off because hopefully that person will no longer be stuck. If I really am so busy that I can’t help, I’ll just tell people that and they usually understand, and then I’ll try and follow up with them later.

I feel that in general we are so afraid of inconveniencing other people, even our good friends. I have good friends who have young kids like I do and they will go multiple years without going on a date without the kids. I’ve offered several times to watch their kids for them (which is not that hard to do since their kids will occupy my kids), yet to this day no one has ever taken me up on it. We’re talking about people that we are good friends with. Yet they are so afraid of inconveniencing us (even though we were the ones to offer to babysit) that they won’t do it.

I don’t really know where this comes from, but it’s frustrating. Several people working together are going to be more efficient that individuals working on their own, and that’s because we can work together to achieve something that we couldn’t achieve on our own. But that won’t happen if we aren’t willing to bother someone else with our problems.

I frequently try and tell people on my team that it’s totally OK for them to bother me. I think my business analyst interrupted me at least 10 times the other day to ask me questions. This made me excited because she wasn’t afraid to inconvenience me with her questions, and as a result she probably got a lot more done today than if she had just tried to struggle through it herself.

Software development is a very collaborative activity, and we will be way more efficient if we ask others for help. So ignore that little voice in your head and go ask someone for help, and don’t feel bad about it.

One of my favorite tricks around changing how a team does something is to get other people to drive the change for you.

This especially applies if you’re coming into an organization as an outsider. Most people are initially somewhat skeptical of outsiders and you need to earn their trust. This sometimes takes a long time, and you might want to change some things before you’ve built up the political capital to drive it yourself.

When I started on my current project, all of the QA testing was done manually, and QA people weren’t involved in the process at all until after the code had been written. As a result, they would get features to test and not have any idea of what they had to test, and many times they couldn’t trust that the requirements were even up to date.

The solution that I was hoping for was to get QA people to meet with developers and BAs before the code was written so that they could come up with a test strategy and acceptance criteria. That way they would have input up front, and developers could automate all or most of the acceptance tests, which would save QA a lot of time. But I didn’t want to bring it up myself.

So I would ask questions in meetings. We all agreed there was a problem, so I would ask everyone what ideas they had to fix it. Eventually someone would give the answer I was looking for. “That’s a great idea!”, I’d say, “How do you think we should do that?” Now it wasn’t my solution, it was someone else’s. That person feels good because they came up with a good idea (that eventually ended up working), and since that person is actually on the team and doing the work, they might have more credibility than an outsider like me.

I would much rather have someone else get the credit for coming up with the ideas, because I think that it gives the idea a better chance of success, and when it works, it encourages people to try and think of more ways to improve things. If one person comes in and tries to drive and enforce all of the change, it’s very easy for people to discredit that person (maybe even just in their mind) and try and fight the change. But when the ideas are coming from multiple different people on the team, now you have more and more people buying in because they’re the ones coming up with the ideas!

When I think of a “coach”, I think of someone who helps other people find the path to success. You can try to push them in that direction and they might turn around and fight you instead. Or you can help them use their own ideas and expertise that they already have to find their own way.

If you want to change something in your organization, that must mean that there is some problem that needs to be fixed and a solution to fix the problem. That’s obvious, right?

Maybe it’s obvious to you. But is it obvious to others?

If other people on the team don’t see that there’s a problem or if they’re OK with the status quo, it’s going to be very difficult to get them to change. For example, let’s say that your team does not do automated testing and you want to get developers to start writing unit tests. The problem is that you have lots of bugs and it’s scary when you have to refactor the code.

But wait a minute, do other people think it’s a problem? More than that, do they think that your solution will be better than the status quo? That’s a completely different question! Maybe the developers on the team have all been getting good reviews from their manager. They might not like the bugs and the scary refactoring, but they might not think that introducing TDD will fix the problem, or they might think that it’ll be more work to learn TDD than just deal with the code without tests.

You need them to both see the problem and buy into the solution (man, this is getting hard). So maybe you go and write unit tests around some part of the system. Then later when another developer needs to change the code, you show them how easy it is to run the tests and see that the code is still working. Now maybe they’re more open to your solution because they can see the benefits of it and see that maybe it won’t be as hard to implement as they previously thought.

Until you can get people to see that there is a problem and that your solution is viable, you’re probably not going to have a lot of success getting them to change.

If you want someone to change, you have to not only give them time to change, but you need to show them that you will be there to support them when they need help. They might be worried that they’ll starting learning the new way and then you’ll leave them out to dry without any help to get them the rest of the way.

The other day I was making a change to a part of an application that I don’t deal with much using a framework that I’m not an expert in. It wasn’t very hard to figure out, but I didn’t really enjoy it. I hate feeling like something is taking me way longer than it’s supposed to just because I’m not the expert in the application or technology. I’m sure you all can relate to this.

Now think about having to do something completely foreign to you, like a new language, platform, or technique that you’re really not good at. Or maybe you’re trying to change the way that your business analysts write requirements or your QA people test software. We can criticize people for being fearful of change, but we’ve all been there are some time.

If you’re the one who knows what they’re doing when it comes to the new whatever you’re doing, look really hard for opportunities to help people. Most people are reluctant to ask for help (maybe they have egos, they think you’re too busy, or they just don’t want to get up out of their chair). Instead, ask people how they’re doing today. When they mention that they’re struggling with something, go help them with it, and then offer to help them again if they need it.

Some people are definitely more adverse to change. If you’re the one proposing the change, chances are you are not as adverse to change as others. You have to try and put yourself in their shoes. They have good, logical reasons in their mind to not do what you want them to do. If you can empathize with them (or at least attempt to), you’ll be more in tune with their fears and what you can do to help them through it.

There are many people on software development teams that are trying to change the way that their team works, whether it’s a new process, a new technique, or new way of development software. Yet so many of them never see lasting change come about.

You can try to drive change or encourage people to change, but the people on your team have to feel like they have some room in order to try and make the change. If they feel that there is a risk of failure because changing the way they work will lead to poor results, then they won’t take the chance.

Stop the fire fighting

I’ve seen many teams that feel like they’re in endless fire drill mode. When you’re in these situations, you have very short term thinking because you feel like you’re always solving short term problems. Sometimes there are fires, but ultimately what we want is more long term thinking. But in order to get that long term thinking, you have to give people some stability and peace in their day to consciously think about doing things the right way instead of doing whatever it takes in order to fix the problem at hand.

This is easier said than done. It takes someone awhile to switch from short term fire fighting mode to a long term mindset. For me, someone may say that the fire fighting is over, but until I can go a week or so with some stability, I’m not really going to believe that I’m going to have space in order to think differently.

This requires you to rethink how you plan your capacity. It probably means that you need to either do less work and get more people to help get the work done. Either way, you need to stop lying to yourself and saying that you can do as much as you’re doing with the team that you have.

This is where making the workload visible is important. Put everything, and I mean everything, up on a board. People should see what you’re working on now, what’s next, and what’s in the backlog. Put technical debt and refactoring tickets on the board too. When someone asks why those are there, explain how doing those tasks will allow you to provide more value and be more productive. If someone asks why you’re not getting as much done as they would like, you can show them exactly why.

It may take discipline, but if you slow down just a little bit to think about what you’re doing and how you can best do it, you can turn things around.

If you’re a developer, why do you do the work that you do? What’s the goal of all of the frameworks, databases, code, and tests that we swim in every day? I’ve been doing this professionally for ten years now, and I’ve noticed an interesting progression, and it wasn’t one that I had pursued originally.

Early on, I wanted to work with new technology. The goal was to do cool stuff with the latest technology and find new, better ways to do what used to be harder in the previous year’s hotness. Working at a consulting company was great for this. I got to do new projects every 6 months that often were greenfield and we usually got to pick the technology. Now we were smart about it and we weren’t just doing “resume builder” projects where to tried to use some new framework for the wrong purpose. We were delivering value. Everyone would always hope that they would land on that cool project using the latest stuff, and whoever wasn’t on said project would want to talk to everyone on the project and see what they were doing.

Two years ago I joined a Ruby on Rails project and spent a year in the Rails world. This was the pinnacle of hot technology (at least at the time). I loved how elegant the Ruby language was, the Ruby gem ecosystem, and the Ruby community’s focus on quality and testing.

Eventually my time on that team came to an end and I came back to .NET. I have nothing against .NET, but in terms of geek cred, many people would consider .NET a step back from Ruby (but that’s not the point).

What I noticed from my transition to Ruby and back is that no matter what the technology, the code isn’t what’s important. What is really important is how we interact with users and how we can structure our process and teams to best deliver quality software in less time. We need to value people over the tools that we’re using.

The longer I’m in this business, the more I realize that software development is all about people. It’s about using technology to help improve the lives of the people who use our software, that somehow we can use our coding skills to help them be more successful at their job. It’s about the people that we work with on our team, it’s about helping them feel everything that comes along with working alongside others to help the team achieve a common goal. It’s about looking out for those team members who are feeling overwhelmed by their workload and struggling to hold on to their confidence.

I still geek out on code, and I’m still glad that I get to spend most of my workday writing code. The means may be the same, but the ends have changed.