What an Average Day is Like at a Software Development Company

Typically, I say hello on chat to let my team mates know that I am in business mode, make a cup of coffee, check my email, check the team’s issue tracking software, and then figure out what I’m going to do today. Often, someone is working from home, which is totally fine as I know they are productive either way.

Then, I’ll jump into coder mode. Pull latest forks from git, open up my dev environment and get into things. In my case, it’s a whole lot of PHP.

software developmentJS, CSS and HTML are the basics any web developer should know very well and if you don’t know them you’re going to not do so well. You should also understand Open Source, and HTTP protocols, and how to use your browsers’ developer tools.

Knocking off Some Code

Then I knock off some tasks, if I have any issues with someone else’s code, I verify things with them. I want to be efficient. I keep the company’s clients in mind, as it’s our business relation with them that trumps all. Pretty code is nice, but so is keeping our client happy. Therefore when it comes down to refactoring everything, or just getting it to work and refactoring things later, decide well, as your happiness in the following weeks will depend on it.

Software will be bigger than your understanding of it for the first month or three. There are reasons that seemingly unintuitive code exists, check with your team before you ever comment out or remove it. Figure out how developers are solving things, because there is nothing worse than solving the same problem in multiple ways.

On my project, we have two teams working. Merging is painful, but I’m not responsible for that level of merge. I merge with my team here, and our technical architect will do the painful big merges. However, I’ve ventured into their code from time to time, to see how they do things.

Programming Language and Frameworks We Use

We are using Angular.js, Laravel and other frameworks and my teammates use it differently from me, but they have an application under their belt and I do not: so I find their code very educational at times.

But anyways, I tend to fix things, add features, make a commit, test everything, pull latest (and merge if necessary). If you merge, retest things. then push your changes into the central repository.

Later, when your team complains that you broke their code, remember that the clients are the end-goal. Don’t take things personally. I end up in some big disagreements with some people, but at the end of the day, neither of us take it personally, because we just have to make it work in the end.

Agree sooner than later, disagreement means more code that could conflict. Planning is good.

Anyways, if you want to make good web applications with a team, start messing around with the various frameworks you might be using.

Clever code is not as good as clear, consistent, predictable code.

Also, write tests.

Software that Works

If you have an API, write some code that will verify that the API is doing what it’s supposed to. Contrary to developing alone, when developing as a team, you never really know who might have broken something, and where it was broken, and if they had any clue what they were doing.

In the end, making the software work as intended without big and painful debugs is what will make it successful. There will be edits later but if you planned it well with your team, everybody will understand how things have been done, what’s the logic behind the code and how it’s been structured. Also, we see to it that code comments are all descriptive so when someone new on the team will work on it, that team member will be able to align with the software structure the soonest possible time.