As a programmer how much are you expected to know outside of programming?

Question

I'm wondering what you do as a programmer that's not programming but necessary for your task (eg: local setup, server setup, deployment, etc). I'm curious to know how many non-programming related tasks people are performing.

For example, when on web development projects I often:

• Install servers
• Manage user right/access to servers
• Perform backups
• Configure IIS/Apache
• Setup FTP sites

On non-web projects I often:

• Write build scripts
• Setup source code management tools/procedures
• Probably more stuff I'm not thinking of

Some tasks are more related to programming than others (such as writing build scripts) but others fall outside of my area of expertise (domain setup comes to mind). Just interested to know how many people perform tasks in their jobs that are not programming related.

Answer 1

This will vary greatly depending on where you are. I've worked with people who know none of this stuff, and people who are experts.

Knowing this will help you greatly. In general it's always better to understand the environment your code is running in. Not understanding the context leaves you somewhat helpless.

Additionally there are often bugs that are not code related but configuration related, for example a page not showing up because of the apache configuration. You're very handicapped in debugging if you don't understand the environment.

Answer 2

Well, since a programmer's primary tool is his computer, I think it's fair to assume some expertise with it. Most of those sorts of things you've described are difficult for someone unfamiliar with computers, but pretty easy (even with little prior experience) for someone who understands the domain and knows how to find and read documentation.

In a big, well-organized business or project, I'd expect someone who was more specifically familiar with those sort of administrative things to take care of them. However, if there's not enough of them to warrant a full-time job, then I don't think it's unreasonable to have anyone competent work on it; and programmers are probably at the head of the queue in that regard.

Answer 3

The sad reality is that non-technical people look at technical people and expect them to know everything that is technology related, not understanding that there are specializations within technology which we might know nothing about.

I often think it is very much like a doctor that specializes in a particular discipline. All doctors have a baseline of knowledge in the medical field, but will not know the specifics of other specializations (a cardiologist will not know as much about anesthesiology and vice versa).

So while I think it is unreasonable for people to expect technologists to know everything, I do think that it is reasonable for them to expect that we know something when it comes to technology.

I think a more important facet of this question is how much one is expected to know about the specific domain where they apply their skills (finance, manufacturing, etc, etc). I think that is incredibly important, as having that domain knowledge makes them much more valuable as a programmer, as they can understand the problems on a deep level, and as a result, provide more comprehensive solutions for them.

Answer 4

People around a work place probably expect a programmer to be their IT HelpDesk guy... it happens around here to me. argh.

Answer 5

Where I work, all developers are expected to be able to use Subversion and have to be able to setup and configure Apache and Tomcat on their PC.

Answer 6

I find the vast majority of "bugs" discovered by users are configuration problems with the systems on which the application is installed. Having developers that understand the common machine and network setup errors is very desirable.

For example if an application sends email as part of its operation its useful to have developers knowledgable in DNS and SMTP configuration.

Of course it depends on your size of business, large organisations can probably shield developers from this by using other specialists.

Answer 7

Probably depends on the size of the company you work for. As someone who has worked mainly at small to medium sized businesses, I've also been responsible for:

database creation, management, and tuning supporting the internal applications I launch managing website certificates setting up external hosting and I'm sure there's more as well

Answer 8

The biggest challenge is not the technical issues associated with getting the environment up and running but the domain knowledge required to effectively develop software in a small shop. For me, I work on a lot of different projects from a variety of sources in a mostly isolated development environment. This means that I need to come up to speed on the domain of the project pretty quickly in order to be effective in developing a solution. In the past I've worked on print accounting solutions, active directory management, research survey databases, and currently a quasi-CRM solution for a charitable organization. I wish I only had to know the nuts and bolts of setting up my development and build environment.

Answer 9

Expected? Almost nothing, but everyone's always really happy when you know more.

The more you know outside the narrow confines of programming, the more valuable you are to your employer.

Things that have come up for me:

• requirements gathering
• writing use cases
• evaluating test plans
• negotiating with vendors
• tax law
• revenue recognition rules
• ideas about how users behave
• basic economic theory
• usability guidelines
• differences in consumer behavior in different countries
• system administration (being a full on sysadmin)
• database configuration, optimization, setup (basically being a DBA)
• monitoring systems
• networking principles and techniques (you'd be amazed how handy a packet trace can be when debugging something...)
• being able to evaluate a business plan written by someone else
• image manipulation
• how to diffuse a situation and avoid arguments
• how to corner someone and make them to commit to something when they don't want to
• how to choose battles

Answer 10

It often depends on the size of the company. In a little company, you have to know how to do everything, including systems admin, and network admin, even if your job is focused on programming.

In a big company, you get to see a little slice of the universe, and they often don't like you peeking outside of your box. Not only do you not need to learn everything, they're often unhappy with you if you try.

However, the more you understanding about the machines, how they work, and how they function in an operational environment, the easier it is to diagnose problems and write better software. The more you understanding about the domain you're writing applications for, the better you are able to differentiate between the users needs and their desires.

One of the coolest things about being a software developer is you have a life long excuse for sticking your nose into both the technologies and the various business domains. If you've shifted around to a few different industries, you tend to become loaded down with all sorts of interesting tidbits. There is always more to learn ...

Paul.

Answer 11

I think the non-programming skill I use the most in my programming job is writing. It's really crucial to be able to explain ideas, designs, algorithms, and so on, and you can never count on being around to do it in person (or having the time). I spend a good amount of time at work writing up design documents and other documentation so other engineers can get their heads around my code and algorithms. So I'm really thankful that I had good writing classes in school and can put a sentence together. :-)

Answer 12

It's good to expose yourself to other technologies, but I really think it's a bad idea for you to not fully disclose the fact that you aren't experts in those areas (esp. domain setup). I've worked with people who thought they could do it all but ended up doing those tasks so poorly that with all the time (and money) they've spent trying to get it right, a consultant would have been paid for several times over.

I've worked at a company where I was responsible for everything "related to a computer" including the domain, PCs, database, custom software, builds, MS Office, PowerPoint, Quickbooks...; a mid-size company where it was development and builds; and a large company where I focus solely on the .Net code for my project (someone else handles the database and another handles reporting).

The mid-size company has been the best experience so far (pretty new at the large company) where I was given enough responsibility to feel useful and had easy access to everyone else to ask questions about those other tasks.

Answer 13

You are not alone out there. The position I signed up for was "ASP.NET Web Developer"... However, my job consists of:

• Windows Server Administration
• Limited Linux Administration (running top to monitor CPU utilization and changing apache configs)
• LDAP Administration / Tuning
• MS SQL Server 2005 Administration / Tuning
• Database Development
• Crystal Reports Developer
• Perl Scripts
• C# Win32 Developement
• C# / ASP.NET Web Developement
• Managing User Access Rights for Windows Servers
• Limited Network Troubleshooting

Being in a company that is constantly striving for supreme "Operation Effectiveness" my task list only grows by the day. I did not make up that list either. All of the items mentioned above, I have either touched or supported in the past 3 years I have worked in this company.

That being said, in a good development shop, you should have one specific task. As the saying goes, Jack of all trades ... master of none.

Answer 14

This depends greatly on what you're programming. If you're doing low level device drivers, it's vital that you understand the underlying hardware. If you're doing a standalone Java app, the better you understand the JVM and libraries you're using, the better - but it isn't strictly necessary to know a lot.

In general, the more you understand about your system environment, the better. How much your peers and management expect you to know depends on them.

Ignorance will, eventually, be punished. If not by your peers and management, the world will do it. Check any week's headlines or RISKS digest for examples where ignorance of the system environment cause software failure.

Answer 15

I realized I'm never hired for the actual job, but as a problem solver. Whether I figure out what's going on, and fix it through code, or software, or something on the network, this seems to be the main perception of what clients want.

Answer 16

[rant mode on] Ha, the curse of Excel and Word.

Outside work - particularly friends and family but sometimes when consulting or delivering software too, any and all non-technical people expect you to understand these. There's that internal groan when someone asks you across to have a look at a small problem they're having with some facet of Office. And because it's a client and you want to appear helpful you agree.

There's just this blanket expectation that because you're a developer you have an innate knowledge of configuring spreadsheets, fixing Word templates, and any and all other office techie tasks, and furthermore you can cast your eye over some badly configured Office mess and instantly diagnose what the problem is.

I can only just about manage to put together a spreadsheet to schedule my reoccuring invoices and set up a Word template to write them. I regularly tell people that too - but no-one ever listens.

Answer 17

It depends a lot on the type of software you're currently developing

For example, when I was working on software for a local government, I had to learn things like

• What are the rules for registering animals (pets). What are the types of registrations, what discounts apply, what are penalties for not registering on time
• How are council rates calculated. How are rates raised yearly (actually, the algorithm for raising yearly rates and its implementation was the most complex task I met so far).
• How are building permits issued. What types of inspections can be performed. Who is involved in the process of issuing a building permit (owner, builder, architect, officers etc.)
• How often are water meters read. How are water meters assigned to properties, how many dials are on a water meter, how to detach a water meter from one property and to attach to a different one
• What are different pension types. What are different discounts that are granted depending on a pension type.
• What are different types of receipts. What different types of terminal printers (those that are used to print small receipts) exist and how to print to them.
• What are properties, strata children, what are rules for dividing properties into 'parcels' ...

Well, that's just part of non-programming stuff that I learned during the 2 years on the project. The most unfortunate thing here is that now that I moved to a different company, there is very little chance that any of this knowledge I will ever use.

Answer 18

My job title is "Senior Software Engineer". In point of fact, for most of the past several years, I did fairly little software development, but did do a lot of:

Systems & web administration

Static web page development with HTML (I don't consider that programming, although I have done PHP, CGI, and JavaScript).

As others have said, help desk sorts of stuff, although not as much as in the past.

As a "task leader", I'm expected to have some people/management skills, although that usually devolves to writing monthly reports. I also get sucked into CMMi stuff from time to time, which in an ideal world might be somewhat relevant, but is usually just record keeping so the employer can bid on new contracts which require it.

Working in science lab, there's a need to know some of the science, especially if you want/need to work on the code doing the scientific calculations.

Working in a (U.S.) government facility, there's lots of paperwork and a need to know lots of government regulation (e.g. Freedom of Information Act)

Fortunately, I've recently made an internal transfer where I'm doing more development work and less of this other stuff!

Answer 19

I am all for deep specialization (it's the only way you can be truly good at something). While I understand the importance of having some basic understanding of the entire stack (so if one day, your co-worker quit, he's not taking the entire company down with him), I think in most companies, people tend to assign tasks to you regardless of what you are good at (it's more product-driven). Eventually, you are swamped with tons of bugs that are outside your skill sets, and you dread going to work everyday.