What tools must a C++ programmer be familiar with when programming in industry rather than recreationally?

Question

I'm interested in the differences in work flow, code management, tools you might be expected to be familiar with etc. Not stuff like "your code will need more rigorous testing", or "your code will need to be more readable/maintainable" or "getting paid"! These are obvious I think. Also, I don't really want a list of the pros and cons of one way or the other.

So I guess I'm more interested in how the process of writing a program changes and the tools used to facilitate that process when you're coding professionally rather than for recreational purposes. Also, are there any specific tools which are common/ubiquitous in commercial C++ development which are not used by recreational coders very often? In particular, how having more than one person writing a program affects the process.

If anything specific to C/C++ on Unix is particularly pertinent please mention it.

I hope my question is clear. Thanks

Answer 1

When I program for a company I have to do what someone tells me to do and I have to spend a lot of time in meetings where people surf the web while we discuss what we are going to do.

When I program recreationally, I do what I want and sometimes I don't even talk to myself. And I waste some time on StackOverflow.

---

Ah! Now we are getting somewhere.

At work, I use Linux, vxWorks, eCos, gcc, g++, clearcase, rhapsody, eclipse.

At home I use Linux, eCos, gcc, g++, subversion, eclipse.

The only difference is that I don't pay for tools I use to do recreational programming.

---

Oh, and I forgot. Bug tracking. Work uses ddts, at home I use Bugzilla.

So the bottom line is I use basically the same methodology at home as at work. Everything under source control, a bug tracker to remind myself about things I can't deal with right now, decent tools.

Answer 2

one you get paid for, one you don't. one you get to do whatever you want, one you have to follow someone else's directions and guidelines, one you can drop for months at a time, one you have to do ever day regardless how interesting or engaging the problem is, one you have yourself to work with, one you have countless other people that may or may not be worth your time talking to much less arguing why copy and paste is not a maintainable solution to a problem. etc, etc.

Answer 3

The difference between professional and recreational anything is really attitude. If you're getting paid for it, you're expected to take it much more seriously, to perform even when you're not in the mood, and to act in a professional manner.

As far as tools are concerned, it depends on the environment. If you're in a UNIX C/C++/C# shop, you'll be expected to be completely conversant with things like gcc, gdb, make, at least one source control system, etc. If it's a Windows C/C++/C# shop, you'll be expected to know how to work in the MSVC environment.

The difference isn't the tools you'll use; it's the depth of knowledge you'll be expected to demonstrate in using the tools. Also in your ability to find and utilize information on your own. Know how to do your own research and investigations.

Answer 4

I think the difference between recreational programming and programming for a company really is down to the individual concerned. Although you obviously get paid for one and not the other, hopefully you are in an environment whereby you can learn from what you do.

Another factor I find is convincing project managers and other developers that the technology or development style I want to use will make a positive difference to the delivery of a particular project.

Clearly when you are developing for a fun this element is removed but I find it always useful to actual ask myself what is the point in this bit of code I'm writing and how will it benefit.

Answer 5

I'd imagine it depends a lot on what company/industry you are doing the progamming for. I work on software regulated by the FDA, so as you'd imagine, I spend A LOT of time doing the stuff described here. When programming for myself or for open source projects, the paperwork tends to be less rigorous.

That said, the tools I use don't change much. Visual Studio for Windows C++/C# and Eclipse with CDT/PyDev for the unix/Linux side. One change though is the money for these tools. When I mentioned to a project lead that I was searching for an open-source Fortran compiler that would play nice with Visual Studio/Windows, he laughed and said "do you know what the budget for this project is, just buy Intels".

Answer 6

There is no set difference. You might be allowed to do anything you like, any way you like, or you might have manacles on every finger.

Answer 7

When you're coding as a work, I see two main differences : one, you'll most certainly have to use source control, and to use it frequently and rigorously. Most of the time, you're working with a team who is modifying the same code as you in the same time. Furthermore, losing X days of code inadvertently will be thought as lost money, not only lost time, and that's of major concern to your manager.

Second, you will have to do much more "paperwork", be it functional specs, justifying your time to your boss or bug tracking, etc.

It should also be said that you will have to live by decisions you'll find intuitively stupid (a tool you don't like, an seemingly obsolete language, an implementation choice you won't agree with...). With time and experience, you'll learn that some of those decisions were actually dumb, but some others were actually justified. And more important, the WHY of both sets will appear clearly. That's called getting professionally mature, and that's the main benefit of working in an organized structure.

Answer 8

The main difference I found was in error control; find a bug which simply isn't going to happen in the real world (and isn't an easy fix), recreationally who cares, professionally ONE OF YOUR CUSTOMERS WILL FIND THAT BUG, fix it.

Answer 9

At home I use new frameworks, beta development tools, tryout anything and everything to help me develop better software.

At work, I do as I'm told but try to bring the knowledge I learned at home with me to make my company and its processes better.

Answer 10

One notable thing I find is a difference in requirements. In home programming, I may program the core requirements and not worry too much about nice to have's.

In real world programming, users may see things as core requirements needing lots of polish that in home programming you'd simply skip over. Some of this is completeness such as globalisation, accessibility (WCAG AA+), cross-browser testing and suchlike.

Maintainability in terms of levels of error logging and alerting are also a major consideration.

Source control and also using aspects of this such as branching and merging to perform concurrent development. Other tools include defect / bug tracking software and also modelling / design software.

Documentation - design documents, support documents etc that I wouldn't produce for a home project.

One key difference is with a home project I'm more likely to get stuck into coding and then discard and reprogram as I understand the problem domain better. At work, a more formal waterfall approach with requirements and design phase is likely to drive out the same issues in a different way.

Answer 11

The biggest difference I know of that I don't see anybody else really discussing here is that if you're writing code for a living, there's a good chance that you'll have a QA department testing the code you write and filing bugs against you.

How do you decide what to work on when you're hacking at home? Usually, that's easy. You simply decide what would be more interesting or fun, and then get to coding. When you're writing code for a living, though... well, it's not so simple.

Since you're talking about tools, I think bug tracking software deserves a mention. Programming for a living means that at least part of your work day has to revolve around checking the bugs currently assigned to you, and fixing those bugs, instead of implementing new features.

Answer 12

For me, its a difference in goals and responsibilities. When I'm writing professionally, there is a quality bar that must be achieved. When I'm writing recreationally, that isn't a concern. Its more about enjoying the work, learning a new framework or getting something working around the house.

Add to that, most of my recreational programming is done on weekend mornings when the coffee hasn't fully kicked in and...well...there's a reason I tend not to share the resulting code.