How productivity or working hours are measured in software development jobs? [closed]

Question

So I will start my job as a software engineer very soon. I've never worked at a company before. What is not clear to me is how people/companies in software development jobs measure their productivity or working hours, especially when having flexible working hours.

I mean in other jobs there is the 9-to-5 working hours theme, where you go to the office and you do a clear kind of job. For example, like being a cashier at the super market. It's very clear how your productivity is measured or if you are doing good. If you are simply serving all the customers and on your chair, then you are doing great! But what about software development jobs?!

In software development jobs it's pretty difficult to measure that. I'm really having a difficulty understanding the working hours atmosphere for software development. I mean, you could be working on a bug and it could take you 2 days but someone else might solve it in couple hours or so. Or, you might be assigned a task to program, but in that particular day your mind might not be at its best so you might not really write a lot of code or so. In other words, giving two working hours, but different personal modes, in one day you can probably write a hell a lot of code in those two hours being very productive, but in the other day and giving the same two hours, you might only be able to write very little code. So how is productivity and working hours are measured in our domain/field?!

I would love to know that before starting my job because I already feel worried and concerned about not being able to be productive during my bad days or so. I mean sometimes you might get a little bit less sleep and be less productive as a coder. But a cashier can do their job even when sleepy, and they don't need to be worried about thinking if they actually truly deserve the money at the end of the month or not, like me! So?

I mean I can definitely try to have a good/healthy life to be as good in my job as possible, but these things are not guaranteed!

Answer 1

A a person new to the work world this is what I would concetrate on:

Know your supervisor's expectations concerning time and attendance. Some places have more flexible work hours than others, some places have the expectation of working 60-80 hours a week. A lot of this is centered on what kind of buisiness the company has. For instance, there are companies that bill time to customers. A company like that is going to have different expectations than one that builds applications and sells them afterwards. And a government agency might have different expectations or a programmer at a company that mostly has a unionized work force in a manufacturing plant. It may also depend on if there is a need for real time production support or not. While company expectations differ, the place to get those expectations does not and that place is your immediate supervisor.

Next find out what the work process is like. Where do you check in code, what are the coding standards, what tools are you expected to use, do you have automated build processes or QA that you have to be able to work with? What kind of testing do they do? What is expected in terms of working together? Do they do pair programming? Do they do code review? Are they agile? How is work assigned? How are deadlines determined?

Next talk to your immediate boss about exactly how he wants you to come up to speed and exactly what he expects in terms of your work. Likely at first you will have many questions. Ask him if you should comne to him or if there is someone else he wants to mentor you. Make sure you talk to him about your first task when it gets finished even if they don't have formal code review. It is far better to find out that you are going in a direction they don't like right away than after they notice six months down the road. Make sure you know the deadline on your first task and communicate if you see a problem with meeting it.

Expect that your supervisor and you are not always going to agree on approach. Remember though that it is generally his job to make the final decision and you must accept those decisions with good grace even when you disagree. The time for influencing a decision is before it is made. Remeber that technical needs or desires are not the only or even the most important factor influencing most decisions. Try to understand what else is affecting the decisions you disagree with and that will help you be more convincing in the future. You will need to build a reputation for delivering work before you will be able to have much influence on the decisions, so concentrate on that first.

Also remember that in business we have deadlines that often mean you can't tweak out that last 5% of perfection. THe perfect is the enemy of the good enough. We aren't creating an art work, we are creating a piece of software that does something and it is sometimes better to get it out there imperfectly than to not deliver at all.

It is better to ask a question than to make a wrong assumption. It is better to deliver bad news (like a problem affecting a deadline) sooner rather than later. It is better to ask for help (well after trying to solve the problem on your own, nobody likes a time vampire either) than struggle and not be able to deliver.

Make sure you check in with your supervisor at least once a month (or preferably more often but it depends on your supervisor's personality) and see how well you are meeting expectations. You will develop more judgement about this as you get more experience, but for now, really pay attention to making sure you get that feedback. And when the feedback is negative, then make a change. Your boss has control over your pay raises and bonuses and even if you are going to stay employed. His opinion on your performance matters more than yours.

Finally start observing the company culture. You will get to know if there are times when it is ok to slack off or or how much overtime is expected to meet dealines or how formally people communicate.

Answer 2

So how is productivity and working hours are measured in our domain/field?!

There's no easy answer to this. If you want a job with easily measured productivity, knowledge work is the wrong field.

There are all sorts of made-up and ultimately pointless metrics, lines of code, test coverage, bug count, feature counts. All of these have significant drawbacks and you should suspect anyone who uses them. I would recommend against using them (even to yourself) as metrics as you can game them trivially.

What matters is "does my supervisor think I am meeting expectations?"

This is something you must talk about with your supervisor about to understand. There's really no other way to know "I am meeting expectations" than to ask your supervisor. Here is a good way how to do so.

---

Just a note, your attitude about this is really judgmental (and wrong):

But a cashier can do their job even when sleepy, and they don't need to be worried about thinking if they actually truly deserve the money at the end of the month or not, like me!

Having done both cashiering and software development, this is not true at all.

Your items per minute will go down significantly if you are tired. It will take you longer to resolve issues. You will be physically tired which will cause you to be slower. You will be less friendly with customers.

Being tired affects your job performance, in all fields.

Answer 3

The best you can hope for here is "qualitatively" - after a bit of experience in the industry, you'll meet some developers who are obviously better than others. There's a well known meme that the best developers are 10x better than others. The specific numbers get argued about a lot, but it's certainly true that there are some very good developers, a larger number of average ones, and some poor ones as well. The trouble with spotting the "best" developers is that their skill sets vary - one developer may be excellent because he writes code which contains very few bugs, while another developer may be excellent because he writes code which runs really fast, and both these sorts of developer are very valuable to the right company in the right circumstances.

The one thing I would be very wary of is any company which tries to measure developer performance by metrics similar to "lines of code written" or "bugs introduced". Any of those is much too easy to game for it to be a useful measure of the skill of a developer - to take a specific example, some of the best bits of code I've written have been the bits which removed lines of code, for instance by generalising some disparate bits of code into one function, yet I obviously wouldn't have done that if my productivity was in any way being measured by number of lines of code written.