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.”
“Come up with meaningful names for data members and functions.”
“There are only two hard things in Computer Science: cache invalidation and naming things.”
“…if you master removing duplication and fixing bad names, then I claim you master object-oriented design.”
2. Explaining what I do (or don’t 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.”
“Explain to my family, what I actually do.”
“Convincing laymans that it does not just mean programming day and night !!”
“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.”
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….”
“I found estimate is the hardest part because most of people usually think it’s a promise.”
“…it is actually impossible to predict task length….”
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
“Dealing with non-Engineers getting in the way…. Dealing with Engineers trying to tell me how to write code…”
“…people with no knowledge about the industry can be hard to communicate with.”
“waiting for other team to finish their work which is blocking us….”
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.”
“Living with finding code written by someone who was not nearly as qualified to write it as they should have been….”
“Trying to decipher thousands of lines of uncommented code.”
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: “…you can either choose to go bananas or go for an early retirement.”
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’.”
“Writing a documentation that aptly explains the working without requiring to go through the code.”
“Writing documentation that is good, explanatory and concise, all at the same time!”
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).”
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.”
“If your design is too bloated, it finally collapses under its own weight; if poor, it is useless.”
“It’s hard to anticipate how things will actually work before you start working with them….”