9 Toughest Parts Of A Programmers Job! 9. Designing a solution The task: Given the requirements of a client, 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. 8. Writing tests The task: Write unit tests, i.e., programmatic tests of small units of software to ensure that individual functions and routines satisfy predefined criteria. 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: 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. 7. Writing documentation The task: Create documentation explaining what your code is doing 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: 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. 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. 5. Working with someone else’s 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. 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 impacted by others and disagreeing with QA people or other developers 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. 2. Explaining what they do (or don’t do) The task: Convey to non-programmers (family members, friends, non-tech coworkers) what your job imply - and also what it doesn’t. The challenge: Being constantly asked to solve any and every computer-related problems. 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 concise.
Posted on: Tue, 29 Oct 2013 04:45:28 +0000
Trending Topics
Recently Viewed Topics
© 2015