Arg! The 9 hardest things programmers have to do

Software developers have all sorts of hard tasks - most of which don’t involve writing code

Arg! The 9 hardest things programmers have to do
ITworld/Steve Traynor, Shutterstock

Most people who aren’t programmers assume that the job of developing software is hard - and it is, but not in the ways that non-developers would figure. A recent discussion thread on Quora got developers to share what they felt were the hardest tasks that the job requires. Using the input and scores from that thread, and another, older one on Ubuntu Forums, ITworld has compiled a list of the 9 hardest tasks for programmers. As you’ll see, it turns out that actually writing code isn’t one of the harder parts of programming. If you develop software for a living, see how of many of these tasks are on your list.

Measure twice, cut once

9. Designing a solution

The task: Given a set of requirements, design and architect the technical solution to be implemented. This can include designing data and code structure, functional algorithms and application flow that encapsulate the business logic and satisfy the use cases.

The challenge: Making sure you design a solution that meets the client’s requirements, which will make sense to them and which can be built in the required timeframe.

Quotes: "Thinking about how to start at point A and end at Z is most def the hardest part." misconfiguration

"If your design is too bloated, it finally collapses under its own weight; if poor, it is useless." nvteighen

"It's hard to anticipate how things will actually work before you start working with them...." jpkotta

Writing tests

8. Writing tests

The task: Write unit tests, i.e., programmatic tests of small units of code to ensure they function properly. These tests help flesh out bugs early in the development process and can facilitate regression testing later when code is modified or updated. Some development methodologies encourage tests to be written before code is developed, while in other cases they are written after the fact.

The challenge: It can be a tedious process to choose tests to write and to code them, which can feel like significant additional work on top of building the application.

Quote: “Writing tests (well it's not hard, I just don't like doing it).” Anonymous

Writing documentation

7. Writing documentation

The task: Create documentation explaining what your code does or how an application works. It can include stand alone documents and code comments. The intended audience can range from end users to other developers.

The challenge: It can be a time consuming task, that can feel like a waste of time if nobody reads it. Programmers usually prefer writing code to documenting it.

Quotes: “Writing useless documents no one will ever read or use, just because it's part of the ‘process’.” Christian Dechery

“Writing a documentation that aptly explains the working without requiring to go through the code.” Raghu Nandan

“Writing documentation that is good, explanatory and concise, all at the same time!” Ayush Goel

Implementing functionality you disagree with

6. Implementing functionality you disagree with

The task: Having to implement a feature or functionality that, for whatever reason, you feel shouldn’t be included but that the client, or someone above your pay grade, insists on.

The challenge: Putting aside your personal feelings and opinions and spending the time and effort to properly implement (and support) the functionality in question.

Quote: “ can either choose to go bananas or go for an early retirement.” Sabbir Asgar

Working with someone else’s code

5. Working with someone elses code

The task: Having to maintain, debug or enhance an application or piece of code that was written by another developer(s).

The challenge: Trying to understand how a piece of legacy code works and divine the intentions of the original developer. This is even harder when that developer isn’t around and the code is poorly written, commented or documented.

Quotes“Trying to mitigate badly documented code.” Omar Diab



Dealing with other people

4. Dealing with other people

The task: Gather requirements from clients, provide status reports to management, work with testers and confer with other engineers about the project.

The challenge: Explaining technical things to non-technical people, having your work depend on others and disagreeing with QA people or other developers

QuotesIt's much easier to convince the processor to do what I want than some people. Marko Poutiainen

Dealing with non-Engineers getting in the way….Dealing with Engineers trying to tell me how to write code... Anonymous

...people with no knowledge about the industry can be hard to communicate with. lnostdal

waiting for other team to finish their work which is blocking us.... Anonymous

Estimating time to complete tasks

3. Estimating time to complete tasks

The task: At the outset of a project, come up with time estimates for the work to be done.

The challenge: Guessing how long something that you possibly haven’t done before will take, making estimates based on vague requirements and trying to allot time for dealing with unforeseen problems.

Quotes“I find it extremely difficult to estimate how many surprises a programming problem will present before it has been tried in practice....” Jan Christian Meyer

“I found estimate is the hardest part because most of people usually think it's a promise.” Samnang Chhun

“ is actually impossible to predict task length....” Jack Menendez

Explaining what I do (or don’t do)

2. Explaining what I do (or dont do)

The task: Convey to non-programmers (family members, friends, non-tech coworkers) what your job entails - and also what it doesn’t.

The challenge: Having your loved ones not understand what you do for a living. Being constantly asked to solve any and all computer-related problems.

Quotes“Attempting to explain to (just about anyone) that I don't know how to fix their computer.” Brandon P-Lost

“Explain to my family, what I actually do.” Utsav Singh Rathour

“Convincing laymans that it does not just mean programming day and night !!” Anand Safi

“To explain people that I'm not the one who has a shop in every corner to install Pirated OS and other pirated software to their PC.” Anbu Jey

1. Naming things

1. Naming things

The task: Coming up with names for variables, procedures, functions, classes, objects, database components, etc.

The challenge: Even a small program or application can require the naming of many things. Choosing names that convey what the thing is or does, consistently across the application and are concise.

Quotes: “Coming up with meaningful variable names.” Aditya Muraletharan

“Come up with meaningful names for data members and functions.” Lakshman Siripurapu

“There are only two hard things in Computer Science: cache invalidation and naming things.” Phil Karlton via Martin Folwer/Jatinder Singh

“...if you master removing duplication and fixing bad names, then I claim you master object-oriented design.” J. B. Rainsberger via Saager Mhatre