3

I'm working as the web developer with some friends who aren't coders themselves, but understand what goes on in the process. So, if it's been a week where I'm tackling a certain issue that I'm really confused by, I try to stay productive while attempting to piece together the new concepts by refactoring existing code, my friends understand.

At a real company, do other teams only care about pushing out new features, or is most sustainable code equally weighed even though there's less to show off?

My role right now is like a one-man-dev-team so I handle everything and some weeks I'm on a roll, but then others it takes a bit to learn how to implement a feature. In the process though, I take a lot of notes, ask questions that I want answered, and try to gain a strong foundation to build on. In reality, do most dev teams try to promote this approach as well?

Thanks!

Improve this question
5
  • 1
    It seems to me that that you may be equating "progress" with "lines of code out the door". When IMHO "progress" is "amount of effort expended to get to where you want to go".
    – Peter M
    Jan 20, 2021 at 17:21
  • You are supposed to do something that contributes to the success of your employer's enterprise. A lot of work may do so indirectly or have a delayed benefit. You are not laying bricks in a literal sense, I think you should regard your productivity as an average over a longer period of time.
    – Martin Maat
    Jan 20, 2021 at 18:05
  • 4
    Software Engineers are Knowledge Workers. In other words: your job is to think. You could go so far as to say that while you are writing code, you are not working!
    – Jörg W Mittag
    Jan 21, 2021 at 6:26
  • Is the work you do helping you towards the goal you have committed yourself to so you can meet the expected deadline?
    – Thorbjørn Ravn Andersen
    Jan 21, 2021 at 9:45
  • To extend @PeterM's comment: would you consider that a taxi driver is not making progress in their job, if every day they return to the depot where they left in the morning? Or is the progress of their job measured in the traveling they do, rather than the location they are in?
    – Flater
    Jan 22, 2021 at 10:19

5 Answers 5

Reset to default
6

During a stand-up, you're answering not one, but three questions:

  • What have you done yesterday?
  • What's blocking?
  • What do you expect to do today?

If you're blocked for the whole week, everybody will know about it, because you will be sharing it five stand-ups in a row.

In this case, the team is not expected to blame you for being slow, but rather to help you to figure out how to solve the issue which prevents you from making progress. This help can take a form of pair programming, or suggestions for a different approach, or advice to contact the persons outside the team who can help you.

Improve this answer
2
  • The OP says they are a "one man dev team", so who would he report to at stand-up? I think this answer makes sense from the standpoint of a team, though.
    – Greg Burghardt
    Jan 20, 2021 at 19:05
  • 6
    @GregBurghardt: the OP also says: “At a real company, do other teams [...]” and “do most dev teams try [...]” My understanding of the question is that the OP is doing it in a specific way, and he's wondering what is the case in actual teams. Thus my answer, which may not be phrased very clearly with the usage of “you” instead of “a team member.”
    – Arseni Mourzenko
    Jan 20, 2021 at 19:50
2

It really depends on the company and the people checking the progress.

In some companies the managers just want to show what was done, and the best thing for that is releasing new feature (because that is what salesmen and clients see). In other companies they understand that the code need to be maintained and clean to avoid code cluttering (and usually those companies are the ones who were first running for new features).

Personally if I'm in a slow week (stay on a specific bug for a long time), I just write documentations to explain everything I do, every step I take to show that work is not always visible for a non-tech person.

Improve this answer
1

ISSUE TRACKING AND ASSUMPTIONS

Most all teams (working proffesionally) have some issue tracking implemented.

They do not track "lines of code out the door" as others have commented on, but the progress on the task itself.

You (and your team) identify the issue and assume how long it's going to take you

The issue could be a bug, refactoring, learning something new, writing documentation or tests. Not all of those produce code or new features.

The time is including self-learning and everything else.

Unless you're experienced with what you're working on, these assumed times change, we try to give ourselves as much time as reasonable (i.e. assume how long it§s going to take and double that).

It's not always possible to have that time and at that point, you either scrap it, change the requirements, move it to some other time (ages and ages hence :)) or pull an allnighter and CRUNCH.

Correct identification of how long something is going to take is a very important skill learned by getting it wrong and learning from it.

Don't be afraid to change the assumption as you learn of new problems/constraints and don't forget to properly communicate with others around you who have an interest in them.

You then work on it and update the issue as needed (update the task in JIRA, tell others during a stand-up, tell your manager on a weekly meeting,...). You COMMUNICATE with people around you as needed.

People who are used to this know that as a junior (assumption on my part since you're asking this) you don't have the knowledge to call the time it's going to take. Even seniors don't know everything beforehand, they do preliminary checks and update/create the assumptions after that.

Tasks are not about how much code you've written. There are a lot of internal tasks (setting up an environment, trying to reproduce a bug, learning something new in order to implement something, refactoring, getting rid of technological debt, writing tests, writing documentation) where you don't write much code at all and instead sink your time to just trying to do something seemingly unproductive.

Improve this answer
1

I would say it's okay to be slow. I was thinking like that as well when I have nothing to do that much or when I feel like a little bit slow. However, it's good to think a little bit about that especially during the "learn" phase. Everyone learn at different pace. One person can try a little bit hacky way and make it works, others wants to put an ideal framework and idea before starting to work. Eventually, both will agree in the middle (in your case, you will find the middle ground)

Improve this answer
0

First of all, you say that you are a one-man "dev team," which actually means that you are not a "team" at all, but a lone wolf. So, "team" dynamics really do not apply to you now.

(Please understand that I do not say this "as a judgment." Every situation is different, and all are valid.)

Right now, you're the only one making the decisions, and you're the only one responsible for your progress because you're the only one who's making decisions about "what you'll be doing tomorrow." This is an acceptable(?) strategy, but only on an extremely small scale. And in any case, it is not a team. "There is no such thing as a 'team' of 'one.'"

In the classic spectrum of "project-management maturity," you're sitting at zero: there is no team, and there is no management. There's just one very-capable wolf. You.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.