What are the most common problems you are asked to solve as a programmer?

Question

Some problems must have seemed repetitive before the days of huge standard libraries.

To prevent duplication, remember to look through answers first before replying.

Answer 1

The most common task I get as a programmer in my small company:

"I can't send emails, can you help?"

Answer 2

The most common that I see are integration related.

Integrate the data from some application into SharePoint for dashboard or automation purposes or parse data from an application so that it can be read and processed by another application.

A lot data moving and translation problems.

Answer 3

its working on my machine!

Answer 4

Since more and more projects these days are in the form of web applications, I'm addressing those specifically in my response. I get a lot of calls from people who think they have the next "killer app" for the web, they are almost always terrible ideas or are already being done.

Anyway, the proposed projects almost always include a need for several of the following:

• User Authentication
• Email Generation
• Content Management
• Social Networking
• File Upload
• Rating System
• Folksonomy/Tagging
• Payment Processing
• Charting/Reporting
• Exporting Data (XLS/CSV/DOC/PDF)
• Affiliate Marketing

Additionally, the proposal almost always expects me to shelf my current projects and put my entire team at work for months to implement their brilliant idea with no compensation except for the promise of a small chunk of profit sharing.

Answer 5

Database table access - "put it in a grid," they say (usually with customizable columns).

Answer 6

"Could you please add this feature that I swore up and down I would never need when we were designing the application?"

Answer 7

Could you provide an estimate for feature X

Answer 8

My most common task is creating Windows Mobile applications that allow access to legacy databases from handheld devices. Basic client/server architecture, with the caveats that everything has to fit on a tiny-ass screen and you can't count on the server's always being reachable.

Answer 9

Similar to the "integration" answer, I suppose, is design.

"We need a set of components that will all do a variant of X."

X can be web-based database access, manage different layers of a natural-language conversation, or run different parts of an embedded device. It doesn't really matter. On some level, they're all going to be similar: guessing which phonemes were heard, which words were heard, and what a logical response would be are all logic/probability/rule-based questions, but they have completely different semantic meaning in a larger project.

Or take the distinctions between login, customer verification, product display, and ordering. Yes, they're all database interactions. But they have different meanings, and they will each inevitably have contrasting business logic requirements.

As a designer, where do you draw the lines? What code can be made very general, and reused, and what really needs a separate function/file/module? Will code that's made too general be confusing? Will separate modules lead to code duplication, and its attendant horrors?

To get back to the question, huge standard libraries (or high-quality standard libraries--not quite the same thing) will only help with tasks that can be easily automated. Zeroth-level design patterns, if you like. But the big issues that undergird the professional practice of programming are largely library-proof.

Answer 10

Actually, I think the most repetitive thing which I've come across is the notion that every business is doing something innovative with the same common business paradigms i.e. the way they view their customers/products, or their sales figures etc.

The reality is that probably 80% of work is with the same entities (customers, products etc), same data (e.g. a person's address, phone number etc) and all we do is implement it in a different way (or for a different platform).

Design considerations are almost always roughly the same - everyone wants high availability, scaleability and so forth. There's usually some degree of difference in each project or product, but invariably we end up working with something familiar.

We end up implementing security models, data access patterns and other considerations which feel similar, mostly because they are.

However, each time we get a chance to perfect our technique a little more. It just gets a little easier to estimate, a little easier to build, test and deliver (hopefully!).

Answer 11

Perhaps this problem is specific only to company with multiple disciplines(PM, Dev and Testers like Microsoft). People have to argue "Who should own this task" every day.

Answer 12

Working with raw data in ways that it can be useful: import into database, graph it, pivot table it, run reports about it, etc. Basically, taking their raw data (which they my purchase, already have in other systems - Excel, flat-files, legacy apps) and making that data more presentable, understandable and reliable for their day-to-day operations. This is 90% of what I am generally asked to perform.

Answer 13

Explaining to management the difference between the design and reality. Whether that is before the development (i.e., what we can actually do) or after (i.e., what we actually accomplished).

Answer 14

Programmer X broke it, can you fix it?

Seriously.

Answer 15

Badly-specified ones.

Answer 16

Can you build a utility that will retrieve my lost password?"

There is only one correct answer to this: If I could, we'd be out of business.

Answer 17

1. Make it modular.

2. "Cant you just use the code from our CRM-system in the cashier-application to handle customers?" No. "What? Didnt you built it modular?"

3. Add multilanguage support. I know we told you to not build it, but you should allways "prepare" for such extentions.

4. Dont put to much time on the "fluff" (error handling, user friendly GUI, data validation) this is only version 1, you can do that when all funtionality is in place. Then after release. "WHAT? There is no data validation!!"

Answer 18

"Write some UI to help customers use part of the app/edit some data/whatever."

"It must expose the full array of configurability so all our customers can use it to do anything and everything they might want, including the one with five PhD's in rocket science. It must also be easy enough to use that all of the rest of them can use it intuitively, despite having never read the manual and having no idea what it's about."

Sure. No problem. That's what you asked for the last time as well...

Answer 19

-- PHB: "This is the most important feature in the world."
-- Me: "But it will clutter the code and make everything less maintainable"
-- PHB: "Everybody will hate us if we don't do this."

A month later..

-- PHB: "Why the hell did we do that for? What were we thinking?"