This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

One thing that you’ll find on pretty much every Agile project is some kind of card wall where features are tracked.

When I started working on Agile projects several years ago, I didn’t quite understand the purpose of the card wall. I thought, wouldn’t you rather just track everything in some online tool?

While tracking things in an online tool is still a good idea, the Agile card wall gives you a level of transparency that it’s difficult to get from an online tool. With a good card wall, you can easily see what everyone is working on, what still needs to be worked on, how long the remaining work might take, and what’s blocking your progress. There is so much to keep track of on a software project, and it really helps when you have a visual aid that can help keep everything in front of you so that you don’t have to juggle everything in your mind (or some online tool).

The trick is to tweak your card wall to give you the most transparency as possible. Here are some things that I’ve found help me get the most of my card wall.

Everything is a task

Everyone puts development tasks on their card wall. However, not everything that your team does could be categorized as a deliverable feature. In fact, there are lots of other things that you might have to do:

• Write up documentation on a wiki
• Onboard a new team member
• Set up a CI build
• Get ready for a demo

These are all tasks that are completed by development team members that take a measurable amount of time. So why not create a card and put them on the board? Maybe you use a different color card to indicate that it’s an internal task. This gives you two benefits — you know what people are working on and you can use the estimate to gauge how much work is left to be done.

Make card walls for your entire team

If our development card wall can help us track what developers are working on and how much work is left, why not create card walls for the entire team? You could have a card wall for BA requirements gathering, QA creating test plans, project management tasks, or some mini-project that you want to track separately. You get the same benefits that you get with a development card wall — you know what people are working on, you can easily see the status of the effort, you can prioritize the backlog, and it can help you get an idea of how much work is remaining.

Make problems obvious

Your card wall should alert you to any problems and blockers as soon as possible, so that you can remove any blockers and constraints that could keep your team from being able to do their job. Some ways that you can do this:

• Create a separate section of your card wall for blocked items
• If something is blocking a feature, put a post-it note on the card and write what the blocker is
• Structure your card wall so that you can see problems immediately just by glancing at it

Let’s look at some examples of some simple card walls and we’ll interpret what we see.

Example #1

In this example, we can easily see that we are either developing things faster than we can test them, or things are getting stuck in testing due to bugs. We may need to assign more people to testing or work on reducing bugs.

Example #2

There are a lot of features that are blocked. We should try and address the blocking issues and look and see if there is some greater problem that is causing things to get blocked. Maybe we need to write better features, or maybe we need to get more time from people in the business who can answer questions.

Example #3

We don’t have much in our backlog, so the developers are going to be out of stuff to do really soon. We may need to get more people working on requirements gathering.

Example #4

Things are flowing pretty smoothly. We have a good sized backlog, no blockers, the work is evenly distributed, and we’re getting a lot done.

The key is that we want to see problems as soon as possible so that we can take the necessary steps to correct the problem and keep things moving.

Address technical debt as part of the process

As much as we hate to say it, sometimes it makes sense to shove in lower quality, untested code in order to meet a deadline. I don’t like having to do this at all because of the risks, but when this happens, keep track of all technical debt that will need to be fixed and create separate cards for fixing it. Make these cards a different color so that they stick out. Then use your board to explain to your manager or project sponsor that you’re going to need some time to go back and fix the technical debt. Many managers want to pretend that the work is done once you release and will convince themselves that they can just move on without addressing the technical debt. You know better, and it’s your job to state that case and show why it’s important.

Refactor your card wall

Your card wall is yours. You create it, you manage it, and it belongs to you. Don’t be afraid to rearrange and refactor your card wall so that it can better meet your needs. Don’t make excuses like “we’ve always done it this way” or “we read a book that said to do it this way” or things like that. Your process and tools need to serve you not the other way around.

Read the next post in this series, Managing the iteration.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

OK, if we’re going to talk about something called “iteration management”, we first should discuss what an “iteration” is. Turns out there are lots of different ways to deal with iterations, so I’ll go over some of the common ones.

Time boxed iterations (the Scrum way)

When most people think of an iteration, they think of a set period of time in which you perform a series of activities and then you do it all again in the next iteration. This is what you usually find in Scrum-based agile environments (doesn’t mean that you have to do textbook Scrum). In a Scrum-based environment, an iteration usually goes something like this (more or less):

1a. Capacity planning – determine how much work we can get done in the iteration
1b. Sprint planning – meet with the business and the team to figure out what to work on, maybe estimate tickets
2. Do the work
3. Demo/UAT
4. Maybe release to production, or at least say that a set of features are complete
5. Retrospective – team meets and talks about what went well, what didn’t, what to change, etc.

The length of an iteration is up to you. I’ve seen people do anything from one week to a month. The shorter the iteration, the less time you’ll have between production releases (if you’re releasing to production each iteration). With longer iterations, you often fall into the trap of doing a bunch of work and then trying to test it all at the end, which ends up being a testing nightmare (now you’re Agile team is just doing mini-waterfalls).

My favorite is a two week iteration. Sure, it would be nice to release to production every week, but I’ve found that the business likes the two week cadence of the process, and they get used to being involved at certain points in the process every two weeks. It also gives you more time to get the work done instead of having more meetings dictated by the process (since you only have those meetings every two weeks).

In the iteration-based model, your metrics are usually measured by the iteration. (For example, how much work can we get done in each iteration?) This model works well when you have a project that you need to complete by a certain time. You need to know if you’re on track, if you need to devote more (or less) people to project to get it done on time, you need to estimate work to know how long it’s going to take, etc.

Continuous flow (the Kanban way)

In this model, you don’t have time-boxed iterations. You just have a backlog where work comes to the development team at any time and they just work on whatever is most important. You might release to production on a regular schedule, or you might release whenever you feel that you have something significant to release. Some teams might even release to production multiple times a day.

The goal in the iteration-less model is not to see how much work you can get done in a certain amount of time. The goal is to see how quickly you can move a ticket through the process (we call this “cycle time”). The idea is that we want to minimize the time between when a business person has an idea and it becomes a reality.

This model works really well for teams that are doing maintenance work or production support (i.e. you aren’t working on a project where people need to know when the project will be done). Things like capacity planning and estimation start to feel like cruft in a situation like this, and it’s much simpler to just bring work to the team and do whatever is most important. You can still have regularly scheduled activities (e.g. demos every 2 weeks), but the process is much more fluid and free-flowing.

Which is best for you?

Only you can answer that! There are no rules on how to do this. I encourage you to think outside the box and come up with whatever works best for you. Regardless of the method, here are some things that I think are important that you should consider:

• How can I most quickly diagnose problems?
• What works best for the stakeholders, management, and the business?
• What allows us to best handle (and even encourage) changes in priorities?

Most of the rest of this series is going to focus more on the time-boxed iteration method of developing software. Many of the ideas will still apply to the flow-based approach, but the time-boxed method is more involved and has a lot of interesting nuances that are worth talking about.

Read the next post in this series, Card walls.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

If you haven’t heard of iteration management before, maybe you hear the word “management” and you think “project management.” It’s similar, but not really. Here’s how I distinguish the two – project managers manage projects across iterations and maybe across multiple teams. An iteration manager manages the work done by one team within an iteration, although there might be some coordination with other teams.

An iteration manager helps to optimize the efficiency of the team. People on software development teams tend to like to focus on their tasks. They will strive to limit distractions and do whatever they can do get their work done, and sometimes this even comes at the expense of the team. In a way, this is good, because if you give someone a task to do, you want them to get it done efficiently. But in order for this team to truly function like a team, we need someone whose head is not in the weeds who can look at the bigger picture and make sure that the team is working in the most optimal way. This is where you come in.

An iteration manager is an unblocker. If team members are blocked by something, the iteration manager should try and get it resolved for them. An iteration manager should be proactively searching for blockers before people raise an issue because some people will either spend too much time trying to figure things out on their own or just not tell anyone that they are blocked.

You might have to be creative with how you do this, but you will learn to see the signs of someone being blocked. If you have a board/wall/online site/etc. where you have the iteration’s tickets, watch for things piling up in a certain status (whether it’s analysis, development, or testing). If you have people on the team that are working on multiple tasks at once, it could be because they can’t finish the first task until they get an answer from someone, so they’ve moved onto the second task. Or maybe you just notice that a certain feature isn’t getting done as fast as you thought it should and it causes you to ask a question.

Overall, your task is to help the team work as efficiently as possible. This doesn’t just mean “fast” (although that’s certainly part of it), it also means that you ensure that software is going to meet the needs of the business and the people that use the software. In order to do this, we’re going to use everything at our disposal, including data analysis, communication, and lots of intuition.

What I love about iteration management is that it allows you come up with creative ways to achieve the goal, and there’s no one right way to do it. The rest of this series is going to give you a bunch of tools, tips, and tricks to get the job done, but ultimately you’ll have to use your own intuition to do it well.

Read the next post in this series, What’s an iteration anyway?

Iteration management is the art of managing the estimating, planning, and execution of a software development project over a short period of time, whether this is done individually or in a team environment. I call this activity an art, because while there certainly is a scientific element to it, it requires excellent communication skills and a strong intuition. You need to understand what is realistic for your team while getting things done.

For some of you, this might be a new career path that you didn’t know about. Many people assume the next step from being a developer, tester, or analyst is to move into some sort of traditional management. Iteration management allows you to stay closer to the team and probably continue doing the work that you’ve been doing while providing value in a new way.

What’s coming

This topic is way too big for one topic, so I’m splitting it up into a series of posts:

• What is iteration management?
• What’s an iteration anyway?
• Card walls
• Managing the iteration
• Estimates
• Comparing estimation methods
• Data analysis
• Consistency
• Personal iteration planning
• Metrics
• Burndown charts
• Capacity planning
• Involving stakeholders
• Keeping up

I found this post that I wrote in 2010 and the 2014 version of myself can’t say it much better, so I’m going to regurgitate the same post for your reading enjoyment.

Go to a software conference near you and you will probably hear talks on new languages, new frameworks, how to design code better, how to test better, and the like. What no one ever seems to talk about is how you can go faster.

We need to get faster at what we do, because it just takes too long. Why do you think companies and managers are always pressuring people to get things done faster? This is a tricky situation though — the challenge is to find ways to get faster without cutting corners, ignoring unit testing, and writing poorly designed code. Anyone can get things done faster by deciding to not write tests or not think about how to design code well, but that’s cheating. That just leads to more bugs and more work down the road.

Don’t ignore the importance of getting things done in a timely manner. I got to be a project manager on a project once, and every day I was looking at our feature wall to see how we were doing and if we were on schedule. I guarantee that your manager or project manager is doing the same thing. That experience and awareness helps keep me from not wasting time adding non-essential features or spending too much time over-analyzing things (be especially careful of this one if you’re pairing). I try to work with a sense of urgency, as if I’m competing with someone else who is trying to complete the same project faster than I can (without cutting corners).

One way to get faster at something is to practice. Find a simple coding problem, like the ones mentioned here. Pick an easy one (nothing with crazy math algorithms, complicated recursion, etc.), or maybe take a complicated one and simplify it. Try and find something that you can do in 15 minutes or less, but still involves writing tests and creating multiple files.

The first time through, go through it like you normally would. Think about design, write good tests, and make sure you understand all the nuances. Then go back and do it again and time yourself. Do it over and over, and try to beat your previous time. At this point, you’ll know how to design the code pretty well, and in order to get faster you’ll have get faster at moving around your IDE, find ways to generate code, or learn new tricks. This is what you’re trying to learn. Remember, you’re not allowed to cut corners! You still have to write tests and write well-designed, readable, clean code. Check your code each time you’re done and make sure you didn’t compromise in these areas.

In sports, there are the teams that are good on paper and there are those who execute during crunch time. You may be good at writing well-designed, well-tested code, but if you can’t get it done on time, no one is going to care. So take time to hone your skills and become a faster developer.

I tweeted a quote today that I found to be very insightful.

A poignant reminder of why I'm here. pic.twitter.com/H9Nkbnm4Qt

— Jon Kruger (@JonKruger) April 8, 2014

You could take this two different ways. I take it to mean that I need to just the right amount of testing in order to be confident that my code works and will continue to work.

You could also see it another way, as pointed out by some others:

@JonKruger I think the line which follows that quote is also important; as an industry, that level of confidence might not bee too high.

— Steven Harman (@stevenharman) April 8, 2014

@JonKruger #coding pic.twitter.com/CV98xQuKDe I admire KBeck but disagree.. Absent good #Tests coder confidence is myth.. #OverConfident = Bugs

— SeattleFan4Dan4 (@TJWilk_WA) April 8, 2014

There are those out there that think that testing is a waste of time and I could see some of them taking a quote like this and saying, “I’m a good enough developer that I don’t need tests in order to write code that works!” (I heard someone say those exact words once, sadly.)

@JonKruger Most developers do the same thing… they just have way too much confidence in their coding skills. ;)

— jared richardson (@jaredrichardson) April 8, 2014

The discrepancy is due to what the word “confidence” means in this quote. If it’s just confidence that it works now, then you might be fine without tests, but if it’s confidence that your code will still be working a year from now after someone else has had to modify it, then you probably want tests. (Heck, I want tests so that I can change my own code tomorrow!) I find that the problem is that on many teams, developers define confidence as “good enough that QA can look at it” and then achieving true “confidence” is someone else’s problem.

Maybe we should change the pronouns.

We (the team) get paid for code that works, so our philosophy is to tests as little as possible to reach a given level of confidence.

Now this changes things. What’s the best way to test as little as possible? Automate all the tests that should be automated. Let QA spend time doing valuable things like exploratory testing instead of doing loads of manual regression tests. Funny how you can turn everything on it’s head when you take what is perceived to be an individual’s problem and make it everyone’s problem!

When we write automated tests, we want to do it in the simplest way possible while achieving the highest level of quality for the time we invest in our tests. Unfortunately, this is easier said than done.

Writing tests can be hard. It’s hard figuring out what kinds of automated tests to write. We can write unit tests, integration tests, functional/acceptance tests, performance tests, or just do manual testing. We have to decide if developers are writing tests or if QA people are doing it (or both). It’s really complicated!

Let’s look at some ways that people sometimes tackle the testing problem and then discuss some different ways we can approach it.

The black box

On some projects, the team is testing a big black box. Usually this is where QA people are doing all the testing and developers aren’t writing automated tests. If you read my blog at all you know that I do not like this approach (unless time to market is really that important) because it leads to lots of bugs and makes refactoring anything really scary. In this scenario, QA testers typically only control the inputs and outputs into the black box (which is usually a user interface of some kind). This leads to problems like having to jump through a bunch of hoops just to test something that’s farther down the line of some complicated workflow.

Tiny slices

If you’re a fan of test-driven development, you will write a lot of unit tests. In this case, you’re slicing your application up into very tiny, testable units (like at a class level) and mocking and stubbing the dependencies of each class. This gives you faster, less brittle tests. You still probably have QA people testing the black box as well, so now we’re using two different approaches, with is good.

I’m not satisfied

While each of the previous two approaches have their positives, they both have their negatives. I’ve already talked about the negatives of all manual QA black box testing, so I won’t go into that again (although I’m always up for a good rant). But writing lots of unit tests has its problems as well. For example:

• Tests with lots of mocks and stubs, and failing tests that fail because someone refactored a class any now my stubs and mocks are all hosed. You know the feeling.
• Testing an individual class or method is great, but my tests aren’t always testing something that has business value on its own.

No limits

You own your application. Your application does not own you (at least it shouldn’t). We also own the testing of our application and should be able to test it in any way that we can think of. The goal is high quality, low cost of maintaining the test suite, and speed to market. How can we best achieve this goal? (And don’t just give me the first textbook answer that pops in your head.)

There is no one-size-fits-all method for testing applications, and there isn’t even one single best way to test a single application. So what if we used many different approaches and broke our system up into chunks so that we can use each testing method to its fullest potential?

In this case, I’m dividing up my application into separate modules, each with its own purpose, function, and business value. Some may have a user interface component and other might just do some task behind the scenes. I can decide how to best test each module individually. Maybe some modules are done with all black-box acceptance testing, and other modules are done with lots of unit tests. Even within the black-box modules, I might still write unit tests. Of course, I’m still going to have some end-to-end tests (manual and/or automated) that test the whole system working together, but I don’t have to test the majority of the functionality this way.

My favorite kinds of tests are ones that test a system working together because I can specify the inputs and outputs and I don’t have to deal with tons of stubs and mocks. Now if you try to test the whole application end to end this way, it can be a bit cumbersome. But if you have a smaller module that you can test end-to-end, now you can have clean, readable, well-defined tests that don’t have tons of mocks, and the tests define some business function that the module needs to perform. My module might still work independent from the UI or the database, so I might still be able to stub those out and have fast tests. This feels like the kinds of tests I’ve always wanted – tests that test a module end-to-end but are able to run fast because I can still isolate dependencies.

Hey, look, it turns out that modular applications is a good idea in general! It’s way easier to deal with lots of smaller applications that work together than dealing with one monolithic application. Those of you with large solution files and long compilation time (I’m raising my hand) know the pain of dealing with large applications.

The emerging blob

We like to talk about “emergent design” and that we can write tests first and let that drive the design of your code. That is true, but your codebase will evolve into a monolithic (albeit well-tested) blob of an application that assimilates all code into it’s large collective.

The only way you’re going to have a modular application is if you draw the lines in the sand up front. This can be really hard to do when you have a newer application and you don’t have a ton of insight to tell you how to keep things separate. Compounding the confusion is the fact that you might have a single database for the application as a whole, which I think is fine. You can multiple modules that use the same database, even the same tables. Sure, it would be better if you can keep the tables in separate databases, but sometimes that’s not possible or realistic.

You might start out with certain modules and then realize that you created a separation that is too painful to maintain. That’s OK, it’s much easier to combine two modules than it is it try and separate things into modules after the fact!

Once you’ve defined your modules, now you can decide how to test them (QA and devs should work together on this!).

This feels better

• Cleaner tests with fewer mocks that test mini-systems that provide some function or business value
• More modularity means I can change code without potentially breaking as many things
• Smaller solution files!

I really like how this sounds.

The “impostor syndrome“… is when you’re pretty sure that all the other coders you work with are smarter, more talented and more skilled than you are. You live in fear that people will discover that you are really faking your smarts or skills or accomplishments.

Ever feel like this?

If you do, you’re not alone. But this feeling is not healthy and probably isn’t accurate.

I know people who are like this, and you probably do too. It tends to manifest itself when people feel that they need to work extra hours in order to provide a perceived amount of value that matches the amount of value provided by people working normal hours.

Why does this happen? I believe it’s because people are comparing themselves to others (unhealthy) instead of looking at the amount of value that they do provide (healthy).

Look, if someone gave you a job or put you in a position, they did it because they see value in you and they think that you can do the job. You already convinced them that you can do it!

Now that you are past that point, let’s focus on the value that you provide. I’m guessing that you can probably come up with a list of value you provide at work. For example, maybe you can say that you’re a solid developer, you like helping users, you have a lot of knowledge of system X in your company, and you’re good at using ORM tools.

Think about the last time that someone left your company or your team. It was pain replacing them, wasn’t it? (Well, in some cases maybe that person leaving was a good thing.) But if that guy who left wasn’t a problem, it probably was a lot of work training someone new, learning all of the things that person knew, and trying to make up for the value that walked out the door. (As someone who just took over for someone who left, trust me, I know the feeling!)

Instead of comparing yourself with others, focus on what you’re good at and how you can provide more value! Come up with a plan of something that you want to do to provide value. Write down the steps that you’re going to take to accomplish it. Then when you make it happen, look back and enjoy the good feeling that comes with accomplishing something and providing value.

That’s what matters! That’s what your company wants from you. They don’t want you to be another (insert name here). They want you to be the best version of you that you can be.

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.