The Toiling Programmer: Succeeding as a Developer

Not sure if you're a toiling programmer? Ask yourself these questions:

• Do you feel like you're drowning, that there's no end in sight?
• Do you get stuck on long running problems (1 or more days long)?
• Are you unsure what needs to be done on a ticket, and yet you continue to work on it?
• Do you often get feedback that functionality is missing after you've shipped the work?

That feeling of dread is cancerous towards your work, your relationships at work and your well being. I've personally experienced it many times during my short career -- it's not a fun experience and that's why I am writing about it.

Work doesn't have be like that. You can stop the cycle and feel way better about yourself!

Manage expectations of other people

For me, one of the feelings of dread comes from thinking of what other people are thinking of myself -- whether or not I'm doing something quickly enough, or thorough enough. Things of that nature.

Part of that thinking comes from not talking to those people often enough. People are quite understanding of someone doing work because that's what most people are doing at work!

Talk to the people about the project that you're working on. Talk about the hardships. Talk about the small victories, the frustrations; people who care about your work want to know that you're interested in it and that you're making progress! Even the 'failures' can be celebrated!

Being up-front and honest will save you tons of time and frustration. Talk to the person who knows that part of the system the best -- they will have great insight into how it works and the 'gotchas' in the system. If you can spend 8 hours solving a problem without help and 30 minutes talking to a colleague about it to get the same result (and the added benefit of having trust between you and your colleague), surely it's worth it to reach out and talk about your problems.

Admit to your colleagues that you don't know what you're doing (one of my favourite phrases) and seek their advice. It's very liberating! Here are the upsides:

• You solve the problem quickly with the help of your colleagues
• You gain the trust of your colleagues (and boss?)
• The problem actually is non-trivial and you did need the help (think of the hours/days you just saved of banging your head against a wall)

Here are the downsides:

• You expose yourself as a fraud (hint: you're not a fraud)
• Loss of pride
• Other people think less of you

On that last note, I don't think that's a valid concern. If someone thinks less of you in this case, then that relationship is toxic. Not being able to rely on the expertise, wisdom, and experience of your co-workers at work is a terrible burden to carry. If someone comes out and exposes themselves as a person who would do that to you, then at least you now know what kind of person they are (net gain for you!).

Learn to rely on your co-workers and to confide in them.

Who to talk to

Talk to your boss. Your boss has the most control over your future at your company. Besides the obvious personal reasons, your boss needs to know how things are going because they are often involved with planning for the future with regards to you, your team, and the rest of the company.

Talk to your project manager. If you have a PM, then they are going to need to know how long something is going to take. Periodic feedback on tasks is just as important as estimates because things often take longer than expected! Keep him up to date on things to maintain that relationship!

Talk to your colleagues. There may be a lot of expertise within your team on the problem that you're working on. Draw upon them and you'll be a happier person. Regular stand-ups usually allow for this communication to happen.

Talk to stakeholders. The people that you're doing the work for are most likely interested in how the work is going! They also can give you early feedback on what you have so far and the casual conversations that you have with them can lead you to new information or even just motivation to do the job well.

Specific Techniques

While I think the most important aspect is communication, being able to apply specific techniques can be very useful. I've come across a few techniques that I think you can apply to combat the feeling of dread.

Perspectives as a tool

Does the problem have you stumped? Try thinking about it from a different perspective. Put yourself in their shoes and start asking yourself what's important and what's not important with regards to the problem at hand. You can use this technique to come up with missing functionality and to come up with unique solutions.

A great example of this is a problem like refactoring code. From a product owner perspective, refactoring code has no direct benefit, and yet they know that there are future benefits to refactoring the code into something more easy to work with. Conversely, your team would love someone to give the code some TLC because eventually they'll have to change some behaviour in the affected code.

What if you thought about this from the perspective of someone who wasn't a programmer? You may find simple solutions to the problems that are presented to you. For example, the person might have ended up going with a simple spreadsheet in Excel. That ends up being a lot more maintainable than a MySQL database + Rails + Web Server. Even if it needs to be online and concurrently accessed, Google Docs Spreadsheets fills this niche!

Think about the perspectives of these people:

• Users
• Product owner
• Your team
• Legal
• Competitors

Talk to the person who made the ticket

This seems obvious to some people, but it's not obvious to others. Talk to the person who made the ticket! Maybe they didn't have all the facts. Maybe they've changed their minds or perhaps the work isn't needed anymore. If you do the work for the ticket without talking to the person responsible for creating it, then that's a red flag.

Say a task will take you 3 days to do the way it's written in the ticket. After talking with the ticket reporter, you find out that the part that would take 2 days to do is more of a nice-to-have, and now the ticket will only take 1 day.

That doesn't mean that the additional work shouldn't be done, though. It can live on in another ticket where, if it ends up actually being that important, the work will be done. Simply put, delaying a feature until it's absolutely necessary allows your team and business to focus on the pain points of what you're trying to solve.

Do something different

Working on something else while you think about the problem can really help you come up with a solution to the problem. Take another small ticket on while you think about the larger ticket and a solution may just come to mind.

Or, just take a walk! Or get a coffee, the options are pretty much endless and each person has their own way of taking their mind off the problem.

Another small point here is that the people who you consulted earlier for a solution may come back to you with a solution as well.

Conclusion

Always keep an open mind while you're developing. You may not realize it, but you probably have a support network around you that you can rely on!