The transi­tion from the academic world to industry requires changes of perspec­tive that are often completely unfore­seen. Sometimes it also requires changes in the way you think and work.

In school and college, software devel­op­ment is rather straight­for­ward. The lifecycle of software is well-understood, and devel­op­ment consists of figuring out the require­ments, settling upon a viable design and writing the code to do the job. However, for practical appli­ca­tions, both ends of this lifecycle termi­nate in virtual black­holes, and in many cases, there is very little direct inter­ac­tion with author­i­ta­tive sources of infor­ma­tion. In effect, this makes it much harder to come up with a software that works consis­tently for all the compo­nents that partic­i­pate in the system.

Another aspect of software devel­op­ment that comes to the fore is the complexity of code. Not only is it practi­cally impos­sible to under­stand all the intri­ca­cies of the software, but a large codebase also makes the process of compi­la­tion and debug­ging a lot slower. This may not seem like a very big deal, but it definitely is: it is much easier to focus on a problem and solve it in a hour than to spend a day doing it, with inter­rup­tions. Also imagine what it would be like to add a printf state­ment to hunt down an error, and then spend fifteen minutes waiting for the code to compile. The best option in this scenario is to figure out the problem using abstract reasoning, rather than practical testing.

The third trick that requires some effort to learn is multi­tasking. Arguably, the degree of multi­tasking is higher on the job, or at least it is more fine-grained. No professor ever asked for project updates more than once during a week, but your boss is likely to want those twice a day. Projects are harder to keep track of when you need to keep juggling between so many all the time.

Perhaps the biggest challenge is that feeling of respon­si­bility that is thrust upon you — getting paid to write software, instead of paying your professor to let you do it. I am tempted to quote Tom Sawyer’s lesson on the distinc­tion between work and fun, but then writing software has always been fun.