Less than a year ago, I was working at a job I kinda liked, doing stuff I couldn’t see myself doing for the rest of my life and wanted a change. One year later, I’m a freaking developer, developing webs and such on the internets for a salary no less!
If you want to hear more about my transition into coding check out this podcast:
Well, depending on where you work, the answer may be none of the above or some combination of the three. While I can’t speak for every developer, I feel my day is fairly typical for a developer, especially a junior. Here it is:
I work with an agile team and a scrum master which means we work on large projects by breaking them up into smaller tasks that are always undergoing change and re-evaluation. Each morning we have a meeting or “scrum” where we go around the table and tell the team what we plan to work on for the day.
I usually have a user story, or task written up by our project manager, to complete, some defects (inevitably) to fix and maybe some support tickets to take care of. Believe it or not, this will take up my whole day…
I sit down at my computer and check my email to see if someone at the company needs me to update a photo or link on our internet site then I sink my teeth into my User Story which usually goes something like this: “As a user, I need to submit my order when I click this button.” Task 1: Create a service to update database with user’s order. Task 2: Link button to this service Task 3: Design Button 4: Quality Testing.
This is a simplified version of what a real User Story looks like, but it’s not far off. Basically, I rack my brain trying to figure out the best way to get from point A to point B and code it up! As the most junior dev on my team, I will often ask another wiser dev for help if I get really stuck but there’s few things some intense and pointed Googling can’t solve.
If I finish my project, I have a code review with one of the other devs to make sure my code isn’t too shitty and completes the User Story in question.
Now time for defects! Ahh, defects, or as I like to call them, unexpected features. There are more than a few bugs to fix in every app we create because users will always come up with a creative way to use a program that you never imagined. I try to recreate the defect and pinpoint where it’s happening then do my best to solve it. This can be fun and also pretty effin frustrating.
My team writes code for software that businesses use and sometimes, that software breaks down, a manager or someone at the store files a ticket and one of us has to fix it. Often it ends up the user is attempting to harness the power of IE6 to run our app or their printer just isn’t plugged in (seriously). Most of the time, we’re just as confused as they are.
Notice I didn’t mention the technology or languages we use to do all these tasks? It’s not that they’re not important but in the short time that I’ve worked here we’ve switched frameworks and had to learn new languages on the fly. I didn’t know SQL, DB2 or C# when I started and I guarantee I don’t know whatever language or framework we will be using in 5, hell 3 years from now! The most important thing I’ve learned from working in for real deal development team is how to solve problems!
That may sound too simplified but the languages we use are really just conduits to fix whatever problem is at hand. Being able to learn on the fly, Google the hell out of a problem and collaborate with team members who are smarter are what it’s all about. This is not to say that solid hard skills in programming aren’t needed but nowadays I don’t get hung up on what language or framework to learn next but what one makes the most sense for what I want to do.