Programming as a hobby or out of curiosity is typically a fun endeavor for most people. Mostly. You can take your time, you can make mistakes, you can abandon the entire thing all together if things get too difficult. There's nothing too serious going on here. Being a professional programmer though, where you get paid a monthly wage and where the website that you work on is as delicate as an ice sheet during summer, is a whole different story.
You can take some time, you can't really make mistakes and abandoning a project is typically frowned upon and may warrant you losing your job. It's still fun though, just in a completely different way. Fun becomes closing a ticket that is assigned to you and that has been an open issue for 3 months. Fun becomes completing a successful site deployment with multiple branches merging together with minimal conflicts. And fun becomes the fact that you do get paid to essentially do the same things that you were doing when this whole thing was a hobby.
But essentially, it's a job, and it brings with it many different kinds of responsibility, such as:
Translate tech jargon to human speech
A big part of your job, is to help translate the technical jargon of for-loops, if-else statements and XML and JSON files into human language that a project manager or business person can understand. And that's not a simple or trivial task.
Programming is complex, but only if you're a programmer. If you're not a programmer, then you can't figure out why sending out emails and phone notifications is such a difficult and time consuming task. So your job is to abstract out the actual behind-the-scenes logic into something more digestible that a non-technical person can work with.
"We have to configure an SMTP server and set up the client" might not be what the other person needs to hear.
The more time you spend as a developer, the more difficult this can become. And that's because your normal human speech begins to blend in with your developer speech.
You might start to use words such as "images", "delete" and "update" as if they are a normal part of the social lexicon. But I assure you, they aren't. When I tell people if they have any images to show, they always reply with "You mean photos?". Yes, I mean photos. But also yes, I do mean images.
So when you are discussing user authentication, payment gateways and server nodes with a non-technical person, you need to break things down clearly and ensure that the other person actually understands what you are saying. Miscommunication in a corporate setting can lead to issues down the line, such as building the completely wrong thing. I've done this in the past. And it's awkward.
If you think that being a programmer is not a social endeavor, then I ask you to reconsider that train of thought.
Follow proper programming standards
There are many levels of standards that you need to follow as a programmer. Starting with your companies set of standards. Every organization that you will write software for typically has some document somewhere breaking down how they expect code to be written, documented, tested and deployed. And within the first week at this job, you will read that document and either agree with it or not. Either way, you still have to read it.
Whether you agree with the guidelines or not though is irrelevant. You should still follow proper coding protocol for your company because they are paying you to do so essentially. The company was there before you and they will be there after you leave, but the code will remain.
The next level of standards are tied to the programming language and the framework itself. There are right ways to do things, and there are not so right ways to do things.
If a particular library is deprecated due to security issues and a new version is released to replace it, then it is your job to replace it. Or to at least notify your employer of the fact and have them decide whether this is something that warrants development time.
Every programming language will experience this at some point. Exploits are found and fixed on a daily basis and, while difficult to track usually, once you are aware of the fact, you should adjust your code to be as stable and secure as possible.
There are also best practices in general that many programmer's tend to follow. This could include naming conventions, line indentation, query structure and a host of other things. While you might not know every single one of those practices right off the bat, you do slowly get introduced to them the longer you work in the field. You also typically have more senior co-workers working with you and providing code reviews.
And the last tier of standards are your own.This will mean different things to different people, but at a minimum it should include secure, up to date and scalable code that other people can read. That includes yourself a month later when you are looking for a hidden bug.
Staying Informed
Every day there are more programmers writing more code building more apps. And that means that the industry now changes faster than it did 10 years ago.
And sadly, there is no real mechanism currently for staying up to date with the latest programmatic updates. There are blogs and documentation sites for such things, but they are scattered and not centralized to any one location. Which means that you will have to find a way to stay up to date on your own.
While I personally try and share as much content as I can on this blog, regarding JavaScript, .NET, Web development and other such things, I also have my list of blogs that I check several times per week.
Click here to check out my recommended blog list.
Truthfully, this is probably not a high priority task that you will face often. Often times when you begin work as a programmer, you are given a website or application to work on and maintain and there is no guarantee that this project is in anyway up to date. It may even use an outdated programming language that has lost official support from the developers. I've worked on plenty of these in my day and "up-to-date" and "modern" is not at all on the to do list for the week.
But that is changing rapidly. There are now more companies that specialize in site conversions than ever before. These companies essentially take older and outdated applications and convert them to use more modern and popular frameworks.
In the near future, staying informed might not be as optional. Which is a good thing in the end.
Maintaining the codebase
Remember, this code you write for work is not your code. You may write it, sure. But it belongs to the company and it serves thousands of people (potentially millions). I often times hear that programming is 'fun' and that's why people do it. And I think that the 'fun' that people talk about has more to do with the non-serious nature of writing test scripts at home.
But when you have to organize, categorize, document and manage this code and it doesn't belong to you, it can be anything but fun. But it is rewarding. And I think that is much more important.
Your job is to maintain that code at the end of the day. Whatever it needs, you type it up and provide it. Sometimes you can go long periods of time without writing any code, but that doesn't mean that you won't be doing anything. There's still plenty that needs to be done with any mature codebase.
For one, refactoring. If you aren't writing new code, odds are you will cleaning up the old one. That includes removing code to some extent, but also generalizing code to reduce duplicity.
You're also documenting typically. Documentation can get outdated insanely fast, as business logic changes and as technology evolves. And a big part of the job is to document those changes so that future programmers can figure out exactly what is happening.
I appreciate when I work at a new company and I can tell how the entire application is structured because a programmer left behind meticulous notes. So the least that I could do, is to do the same for a future developer.
Last notes...
There is a lot more to working as a programmer that I did not get to cover here. Coding is, of course, the most important part. You will inevitably write tens of thousands of lines of code at any job while you are there. And that can be both fun and frustrating, depending on the progress being made.
But at the end of the day, you real main job is to maintain that code and to ensure that nothing happens to it. And that alone, is actually always fun.