Before I got into coding, I always imagined it to be a lonely type of work, just me and the computer 9 to 5 coding away, for a lot of people that is not an issue, but I am a people's person ( most of the time at least ) but when I started I found out that coding has a community like none other, a very welcoming community of people doing things they are passionate about, I also found out that work is not a solitary affair as I thought.
In this blog, I want to share some of what programmers actually do at work and how they go about it, different companies have different cultures, so you might not find all these in every company but at least it gives you an idea of what sort of questions to ask during an interview so you join the companies with the right culture for you.
In a lot of the scenarios in the blog post, I will assume that you are starting off as a junior developer and this is your first coding position at work.
1. Fixing bugs - Something Not Working as Expected
When something is not working as expected or has a side effect that is unexpected and not wanted, it is called a bug.
Example of a bug: when a student registers on our system, they are sent a welcome email along with a unique passcode so they can log in to their student portal, something has gone wrong and the passcode is not being sent to the students.
So your task would be to figure out through tracing the code to see where the error occurred and fix it.
Fixing bugs is very common when you start working as a new coder, it is a very good way to introduce you to the system, you will learn the process that the company uses for patching up code and releasing that code to the public, you would usually have someone to report to when it is fixed or if you are having any difficulties.
Bug fixing plays a big role in all companies you will likely work in and is also a big chunk of work that programmers do on a day to day basis.
2. Adding a New Feature - App Is Growing Needs Some New Features To Meet New Demands
As you progress through the company and getting more familiar and comfortable with the code base, you will quickly move on to adding new features to the company's application code base.
Example of a new feature: After a student has completed registration online, add a button in the student profile area that allows that user to terminate their account.
When working on adding a new feature, some companies will attach a time factor, this is how long it should roughly take to complete the work, this is a guesswork, so your team leader will say something like “this task should take you this morning to do and we can catch-up 1:30 pm” if you find that you are stuck or have a question that needs addressing then you can ask your team leader or any other programmer nearby.
I love adding new features when I start at a new company, it is like leaving your signature stamp, long after you have left the company and you meet someone who started working at the same company, you can say, I added the button that allows students to terminate their account :)
3. Demo Of Work Done - Show Off Your Coding Skills
After you have worked on a small piece of work, this could be fixing a bug or adding a new feature, you can demo that small piece to someone, this could be your team manager or the project manager.
The best person to demo what you have done is usually the person who created the task in the first place or someone who fully understands what you have just worked on.
In bigger companies, it is quite common for teams to be split up and each team have specialised knowledge about a group of newly proposed features or bug fixes, in this case, someone from such a team would be in a better place to test your work.
Most companies use an internal messaging app such as slack or skype as a way of talking to each other when you are done with a piece of work, you announce it in a slack app group for example, and someone would grab that piece of work and test it for you.
There is a lot of collaboration work between coders, this is something I really enjoy about coding, we all have different styles of coding and different ways of approaching a specific problem, it is always interesting to see how other coders view the same problem that you are working on.
4. Writing Automated Tests - Prevent Accidental Change Of Behaviour
Something else that takes up a good chunk of a programmers day at work is writing automated tests, you might be wondering what these are so let me explain.
Every time you fix a bug or add a new feature to your companies app, you have to test it to make sure that it works right? Makes sense to do so, otherwise, you will end up embarrassed when someone tests what you have done only to find that it did not work.
So how do you go about testing your work? You click around and make sure that it does what you expect it to do and it doesn’t do what it is not expected to do, this is manual testing, automated testing is when you write a piece of code that does the same testing for you without you having to manually do it yourself, super cool huh?
So we write a piece of code that would for example, on its own, visit registration page, fill in students credentials and then click on submit, the code will also check that a new students record was saved to the database correctly and that the page redirected to a success page, we can also write another automated test that checks that when a students don’t fill in the required fields but tries to click on submit button a warning message is displayed and success page is not shown.
The cool thing about tests is that we write them once, and we can run them automatically over and over again and it checks that all our logic is working as expected.
When you do a massive refactor of your code or maybe you add a new feature, rather than manually testing every aspect of the app, you can run your automated tests to make sure all your features are behaving as expected.
One of the important questions I ask during the interview stage is if the company I am applying to have a well-tested code base (automated tests).
If they don’t it usually means a lot of bugs will creep into the code base and general panic everytime you add a new feature as you are never sure what that feature has broken elsewhere in the system, and it will generally take a long time to test other aspects of the app to make sure that everything still works well.
I prefer a code base that is well tested, it means I can add features, fix bugs with a peace of mind.
5. Front-end and Back-end Meetings - Agree On Work To Be Done
In a lot of companies, especially the medium to large size companies, there is usually a divide between front-end coders and back-end coders, let me explain the difference between these two.
The Back-end coders are usually the ones who work with the server side of things using programming languages like Ruby, Python, PHP and so on, the Back-end coders would also design databases and connect them to the Front-end.
so the front end would design the form and implement it using HTML and CSS the Backend-coder will make sure that when the form is filled in and clicked it saves the data into the database, this is done using a server side language e.g Ruby.
So now that we know the difference between Backend and Frontend coders I also need to point out that in smaller companies, it is usually one person that does the work of both Back and Front, these guys are sometimes referred to as Full-stack coders, this has advantages and disadvantages that are beyond this blog post, but what I need to explain is that meetings occur between the two sides.
If you are a full-stack developer you can also take out time and have a word or two with yourself, not much fun but it is an option.
Part of a coders day to day work is to communicate with the Front-end coder and vice-versa to agree on what each other is going to be working on and maybe in what order so that Front-end can design layout knowing roughly what sort of data Back-end would be sending to the front-facing part of the app.
If you are not keen on working as a Front-end coder but choose to focus on just he Back-end work, it would be best to find out during interview phase if the company you are applying to have a separation of the two types of coders.
6. Morning Standups - Work Done Previous Working Day and Plans For Today
Morning standups is a short period in the morning when all developers usually standing in a circle of something that resembles one, and each developer would spend a few minutes discussing what they worked on the day before or the last working day and also what they plan to work on that current day.
This makes it very easy for everyone in the team to be aware of who is working on what part of the app and also a perfect opportunity to voice any concerns they might have, this saves a ton of a headache down the line.
It is very common that you mention in your morning standup that you are going to be working on so and so only to find out that someone has worked on something very similar and they can share the steps they took with you halving the time it takes you to do the work.
As a new beginner in a company, this is a very fast way of getting up to speed with various parts of the app, especially when you are going to be working on a very big project
In each standup you get to learn something new about different parts of the project when you then start working on a piece of code you know who to ask questions, someone you overheard in the standup talking about the same part of the code you about to work on.
Unfortunately not every company have standups, so it is something worth checking before you decide on which company you are going to work with, in a small company it is easy to get away with not having a standup each morning as the project is usually not so big and everyone have the same level of understanding of the app, but I tend to like standups anyways, any excuse for a chat is always a good thing.
7. Preparing For A Deployment Release - Put Completed Work Out For The World To Use
Once your new feature or a bug is completed and tested locally along with automated tests, the work is combined together with other developers works and put up somewhere for further testing by a product manager, in most companies this is put up on a staging server that only developers/company employees have access to.
When everyone is happy that all the features that have been worked on in the last 2 weeks or so do what they are supposed to do, then all that work need to be released or deployed to the production server for the public to use it.
As a new junior developer the chances are that you will not be doing this just yet, but knowing that it is something that needs to be done is a very important part of your learning process, usually the process to deploy or release to the production server would be the responsibility of a few coders, this helps to minimize the chances of errors.
In some companies where more time has been put into planning the process, putting a project live is as simple as clicking a button and in other companies, this process is written down and have to be followed religiously or else!
So preparing for a release and then pushing code onto a production server is another responsibility of coders at work, most live deployments happen earlier in the day to make sure that a rollback is possible during working hours and also never a good idea to push anything live Friday afternoon unless someone would be working over the weekend just in case something broke due to deployment.
8. Pair Programming - Problem Shared Is Problem Halved
This has to be one of my favourite aspects of coding, this is a chance to work with other developers where you share the same screen and take turns in coding and working on the same problem.
As a junior developer, you will find that you grow very quickly in your understanding of coding by working this way, you will be surprised to find how very differently we all approach solving a problem, there is always something to learn when you pair programme.
Even when you work remotely it is still possible to pair up with other coders using various online apps such as Teamviewer or GoToAssist and so on.
You see what I mean by coding doesn’t have to be a solitary business where it is just you and your laptop, there is a very good amount of communication involved in it and lots of chances to grow in your newly chosen skill.
It is worth pointing out that even seasoned programmers when pairing up will often learn a thing or two from you the beginner, especially when you have only recently been reading up on the documentation you might have found something they missed, so you also get to teach your senior devs a thing or two :)
9. Sprint Review & Planning - Distribute Tickets For All Developers
Sprints are time interval set aside for all coders to work on creating a chunk of features that need adding into the company app, this can be 1 or 2 weeks period interval.
For example every 2 weeks all coders and project managers will come together, look through or create a list of new features that need to be added into the app, and then allocate those features as “stories” to different coders, the aim would be to complete these feature within the next sprint period.
A story is just an instruction telling you exactly what needs doing for a feature to be seen as completed. Example of a story would be: “before a user can view a list of students in the app, the user needs to have logged in.”
This is also the time for reviewing the work done in the last sprint period, seeing what challenges coders have and what can be done to avoid it, looking into the processes used during that sprint and seeing how to improve them, making note of tasks that weren’t completed in the last sprint and adding them into the coming sprint and so on.
Depending on the size of the company, sprint review & planning can take up an entire day, I have worked in companies where that was the case, as well as companies where sprint periods are shorter and the planning and review takes a smaller portion of a day.
10. Pull Request And Code Review - Your Code Goes Into The Main Repository
When you start working for a company, you pull down from a repository a copy of their code, and you can work on that in isolation on your own laptop, this is the code that you can make changes to, adding new features or fixing bugs and so on…
When you have completed your work, and you have tested it on your computer and you are happy with your work, the next thing to do is to take that copy of the code which you have modified and merge it into the main code repository, so back into where you took the copy from.
The process of merging your work back into the main repository is called performing a pull request.
This is a time for other developers to have a quick look at the code you have written and if anyone spots something that might have a bad effect on the rest of the code or something that simply needs improving, then the pull request will be rejected with a message pointing you to what needs fixing.
When you have fixed the issue, you can push your code back up again and this time if all is approved, your work can then be successfully merged into the main code repository and will be deployed live to production server during next deployment life cycle.
Pull request might sound like a scary process where your code is judged and found wanting, but it is not the case at all.
Everyone, both senior and junior have to go through this process, so you also get to review other coders work, this is a very good opportunity to learn how people approach and solve an issue.
I personally learn a lot from reviewing other people’s code and I think you will too.
As you can see from the above, programmers don’t work in isolation, there are lots of interactions going on at the office between different teams of programmers, this is also the case if you are working remote and have to connect with other via an app such as “slack”.
Of course, there are times when we need to have a quiet time to get a particular piece of work done, in such times we put on a headphone plug into the system and code to our heart's content in isolation.
Hopefully, now you know a little more about the high-level processes that keep coders occupied at work, a gentle intro into some of the things that you too can find yourself doing in the future.