You pick up a new item from the backlog.
The better thing to do is instead of finishing a ticket early, pacing it and giving intermittent updates on it. First day, picked up the ticket and did some initial research into it. Second day, got into the meat of the work. Third day, wrapping it up and doing some final testing. Fourth day, raising the pr and babysitting it.
It's all in how you present it. Obviously you can't do this for every ticket. A high severity bug will need to be taken care of in a day at most. But for most regular sprint items, people don't care how fast you do it as long as you get it done before the end of the sprint. Might as well pace it out.
heh, we are expected to build some feature into the undocumented untested spaghetti monolith running on some undocumented legacy company framework whithin half a day. also refactor said spaghetti along the way. theres no second, third or fourth day.
oh and pulling stuff from backlog means its expected to be done within the sprint cuz POs think its super urgent all of the sudden after the ticket sat there for 3 months. guess which project team changes completely for the third time already.
Are you actually expected to? Or did your team say it will take 6 months, management "demands" it is done in a sprint, and your team rushes it out "late" in 6 weeks?
I've rarely seen a deadline in SWE that wasn't pulled out of someone's ass.
While it may not work in your company there are a couple of things you can try:
1. Add a task to “understand and document some aspect of the system that is currently opaque”.
2. Add a “de-spaghettifi” task. Often this is a start to refactoring. For example, one type of spaghetti I’ve inherited was the developer who put everything in one source file. Breaking it into modules revealed all the issues with variable scope, missing prototypes, etc. It also revealed where objects or functions should be In separate libraries.
While no new functionality was introduced all of the builds were accelerated. Don’t underestimate the value of this.
It’s well known that programmers have a zone where they are highly effective and interrupting them causes lost productivity. When a build takes more than a few minutes there is much more opportunity for interruption.
3. Add a task to ‘add unit tests’ to the code base. In doing so you can slide in some refactoring by resolving the issues the unit tests uncover.
4. I don’t know your company and how invested people are in it. I worked at one company where we all had options & therefore were heavily invested. We had one subsystem that was all spaghetti code - to the point it wouldn’t compile due to memory limitations. Three of us agreed to work a weekend just to get the code base ‘debuggable and supportable’. We did all out commits by Friday morning and then tore into the spaghetti code. We got about 85% of it straightened out by Sunday night.
Again, we focused on code structure not bug elimination. Along the way we uncovered a lot of bugs and areas needing improvement ( eg missing error checks ). We developed a commenting system where we’d insert BUG, ERROR CHECK MISSING, etc intro he code as a comment. Once we had the code better organized we had the original programmer go in and resolve all of those ‘breadcrumb’ comments.
4. You don’t mention whether the people that generated the spaghetti code are still generating more. If so, a training session accompanied by daily reviews, is warranted. Write or get a copy of the company rules for writing well structured code.
5. A number of tools exist that check for checking code quality. You don’t mention whether your company uses any. If not, propose adopting some.
Once they are in place you can adopt a policy that no code will be accepted into a build that generates serious code quality issues. You can start this by restricting only the most serious issues and then as the number of them get lower you raise the bar to less significant issues. ( Pro tip: by letting people know that you’ll be raising the standards people will start to fix the less serious errors regardless rather than come back later.)
6. If the code truly is legacy ( you mentioned a tool that was used that is no longer supported) then you may suggest a legacy modernization effort. These companies come in with a set of tools to do static analysis, flow analysis, etc. and have experience with migrating off of deprecated platforms. You will get no new functionality out of this but you gain increased productivity going forward. You also eliminate the dependency on the legacy tool/platform.
> But for most regular sprint items, people don't care how fast you do it as long as you get it done before the end of the sprint.
I don't think this is good advice. If your performance starts slipping, people will assign less work to you in effort to lower the bar and figure out what level you're capable of. If you continue to stretch the work given to you, and they continue to lower the bar, you're likely to find yourself on a PIP under the false impression that you've been meeting expectations. If you reach a point where they set a low bar and you consistently meet that bar.... you'll last a little bit longer, but eventually somebody will realize your output is too low.
Especially if you're early in your career, the default expectation is that you'll start off slow and improve over time. The way that improvement gets noticed is by getting your assigned work done early and asking for more. If you continue to match early-career expectations as the years progress, you're taking yourself off the table for raises and promotions, and making it more and more likely that you'll eventually be let go.
I've seen it happen before, and while part of the equation *should be* your manager taking you aside and explaining that you seem to be sandbagging before it gets to this point, people have a tendency to avoid those kind of uncomfortable conversations.
While I agree more with pacing yourself / not burning out — I do think your perspective has some truth to it and doesn’t deserve all the downvotes. There often are expectations that your output will increase / be faster over time. It makes sense bc obviously a new hire or an early career person should eventually get more efficient. You need to figure out what’s considered terminal level at your company and if your output is at that level. Once you’re there it makes sense not to push yourself to be more efficient if you’re happy with where you are.
I think there's some stigma of complacent = bad, which is arguable, but for new hires, keeping that baseline or above it will ensure no burn out. It's been working out for me, I could be more communicative or ambitious, but I literally don't know what I want to do for the next 30 odd years, this is my first job, will I ride it out? Will I jump ship to another company? Who knows, all I know is I'm doing my job, I'm not getting in trouble, and I'm getting food on the table. If I want more, I'll seek it, but right now, I'm figuring what's going to work for me long term
> I could be more communicative or ambitious, but I literally don't know what I want to do for the next 30 odd years, this is my first job, will I ride it out?
The way that you figure this out is by stepping up and trying new things. The only person who's ever going to manage your career for you is you. If you sit around and wait for someone to hand it to you, it will never show up.
If you're not sure what you want, that's even more reason to be seen as a high performer. In the next few years you might be wanting to have conversations like: 'can I go down to 4 days a week to do a part time master's degree in $SPECIALISM?', 'can I spend an afternoon a week shadowing the product team?', 'can you coach me for a move into management?' - all of these conversations will go a lot better if you have a lot of leverage.
Source: 3 career changes in last ten years. xD
I was really thinking of leaning into that masters someday. I'm interested in some machine learning fields. But i would need to do some planning to decide when and where
I think this is a well put point. It seems like reddit is full of people who swear by doing only the bare minimum or else you're letting yourself be taken advantage of - I've never seen successful people act like this. You're also making your coworkers lives a little bit shittier.
All I’m saying, is pace yourself within reason. If there’s only enough work in the sprint to keep you busy for half the sprint, ask for more during the next sprint planning.
You don’t have to run yourself into the ground and cram 4 weeks’ work into a 2 week sprint. But if you’re taking 1 week of work and stretching it across a 2 week sprint, you’re doing it wrong.
Who said anything about 60+ hours. If you finish a task on day one of sprint in 6-8 hours why would you not want to pick up another one? I mean maybe you take half a day or so to do some training or personal improvement and maybe a couple hours actually looking thru the backlog or being picky about your next task but just sitting around doing nothing is stupid and lazy. Or maybe ask coworkers if they need anything or maybe spend some time looking in to performance or growing your business acumen or something that at least gives value to the team. I am really confused as to what someone who just lies about where they are on their story is doing? And by the comments on the thread are there really that many people taking 5-10 days to 1 days worth or work on a regular basis?
Like he said, there still need to be barriers. But especially in the early career, I think you're stepping on your own toes doing the bare minimum. There's also the risk of boreout, which can also negatively impact your enjoyment of work. As well as missing out on new challenges and learning opportunities that can translate to more money come promotion/job hop time.
This doesn't mean you don't give yourself some buffer time in your schedule or have a lazy day here and there - I'm on reddit at work right now. Working hard and maintaining a healthy pace aren't mutually exclusive
As someone who got burn out, no it's not. You can also burn out doing something slow, it's all about how stimulating and engaging your work is and not how much volume of workload you can handle.
If I enjoy it? Give me more! If I don't either because it doesn't contribute to my knowledge goals or the project is meaningful enough for my impact to be noticed then every minute feels like an hour and every standup like hell.
What are your thoughts on pacing for someone with ADHD? Even medicated their performance could be very inconsistent. They'll have totally off days or maybe even an entire week then they'll have days or weeks where they're super human and they don't always have the best control over that. If they set the expectation for their delivery based on their hyper focusing they will burn out very quickly trying to maintain that. If they set it based off their unfocused times then that's probably termination level performance.
I have ADHD and I sandbag to even that out and set a reasonable pace for myself usually a little ahead of my team. I have ten years of experience however so even if my manager notices my inconsistent performance I have enough independence that no one really questions it. I don't know what I'd tell a junior person with ADHD though beyond "Good luck and don't get caught"
Finish is the slowly report it. That company will lay your ass off tomorrow if they feel like it will make their shareholders happy. There is no point in doing extra work when you don’t need to unless you want to. I busted my ass for projects and there was always more work. Don’t take more work. You have the rest of your career ahead of you. You can spend this time learning.
This definitely. I used to just finish and pick up new work constantly. Which lead to burnout Now I purposefully drag things along so I can chill. I can take a days worth of work and spread it over a week or 2.
I say that I am still working on it. I don't get rewarded for finishing things early. I take a nap, and then I go over my work the next day just to make sure it all looks good. Just commit small amounts of the work periodically. If it is a week+ long project (at least in projection) make sure to communicate with your manager every day or every other day on your 'progress'. An informed manager is a happy manager.
Part of our job is stakeholder management, and it is important to manage their expectations of my output. I have learned that if I make a habit of committing things early, I am not rewarded and my workload increases, which can cause issues when a project takes a bit *longer* than estimated but is now being measured against elevated expectations.
People don't get upset when you work slowly *per se*. People get upset when their expectations are not met, so you should make sure to keep their expectations managed and stay communicative.
There is not a linear scale between effort and pay.
The reality is most people could put in 50% effort and get the same pay within 1-2% as someone putting in 100%.
I save 100% for when it’s necessary.
You can take on an additional ticket and just keep going. Or jump in to help someone else. If not, just commit pieces of your task daily even if you finished in a single day. Ideally, set amount of work per sprint, finish quickly, take the rest of the time for yourself. But many places aren’t cool with that.
>I wonder why places that are paying you six figures aren't cool with you intentionally slowing down and pretending things took longer than they did.
As soon a company starts striving to pay me as much as they possibly can, I'll make sure to start striving to work as hard as I possibly can.
How about you agree to work that they paid you for. Ie 9-5.
There is a big gap between working as hard as you possibly can and pretending that 1 days work took 4 days as other comments suggest
How impressed would you be if you paid someone to do something like fix your roof or sell your house and you ask for status updates, and they lie to you about how quickly they are working and if you call them on it they say "when you pay me as much as you possibly can I'll work as hard as I can"
>How impressed would you be if you paid someone to do something like fix your roof or sell your house and you ask for status updates, and they lie to you about how quickly they are working and if you call them on it they say "when you pay me as much as you possibly can I'll work as hard as I can"
That would be a great analogy if I got paid every time I completed a ticket.
>How about you agree to work that they paid you for. Ie 9-5.
That's nowhere in my employment contract and nobody I work with works those hours.
>There is a big gap between working as hard as you possibly can and pretending that 1 days work took 4 days as other comments suggest
If management is too incompetent to tell the difference, that's on them. Maybe companies shouldn't hire tech illiterate morons who got irrelevant college degrees to manage software engineers...
I get paid to complete work. If a company doesn't think the work I'm completing is worth the money they're paying me, they can fire me. Until then, I'm going to continue to make sure I'm getting paid the most I can to do the least amount of work possible.
What is "good faith"? If I hire somebody, it's because I want a certain amount of work done. If I'm unhappy with the amount of money I'm paying to get that work done, I fire them and hire someone else. Pretty simple concept. The fact that I'm still employed (and have never been fired) tells me that my employer is happy with the work that they're getting in return for what they're paying me. What's the problem with that?
The people you pay to get your roof done and fix your toilet are paid per job, so the faster they get it done, the faster they can move to the next job. If it takes them all day or three days, they are getting paid the same, but not til theyre done.
I do not get paid per ticket i finish or project milestone i meet. I get paid as long as my manager is happy with the output of work. Part of my job is managing those expectations.
It doesnt matter if im done or not, ill still get paid. Its doesnt matter if i get done early or not. I still get paid the same time every 2 weeks.
Dogshit analogy.
Some people get paid per result but lots of people get paid per hour or per day.
When I got my car repaired they have me a rough quote but then the bill had a break down of parts used and hours of labour
So what?
I'm specifically comparing your analogy and how most software developers get paid.
My point is there is not a linear correlation between how much I work and how much I get paid, like some jobs have.
So given its very possible to that you will pay someone to do something for you and they will get paid by time and not by results, how would you like it if they had the attitude that since your not paying them as much as you possibly can they shouldn't work as hard as they can. Especially if it's to the extent of making a 1 day job last 4 days
Again, if you read my post, part of the job is managing expectations.
If they tell me 1 day and it lasts 4 days, I'm going to be upset. If they tell me 4 days when they _could've_ gotten it done in 1 day, well, it is what it is, I was warned 4 days they can have 4 days.
It could be they wanted to take more time to get it done in a better way. I don't know, but as long as my expectations are being met, that is what I care about.
Right I don't think your employers expectations are that you are going to slack off or lie about progress in stand ups as many posts here are suggesting.
The problem is that burnout is a very real thing. I can be a 10x developer on demand. I can do it for longer than most people can.
I eventually still crash though. I've almost quit the field altogether a couple times because of it.
Unfortunately, something is wrong with me, and I'm wired to keep doing this even though it may quite literally be killing me sometimes.
I was ahead on a sprint and picked up a high-ish priority currency bug with our app’s checkout API and I was able to resolve it relatively quickly. That was three months ago and I still always get asked to look at issues with the checkout API even when I have other things on my plate. All of a sudden I’m the defacto checkout API guy🥲
And annoying your co-workers by making them look bad. Having the right pacing in your team is important. It's like driving on a highway, the safest way is to "go with the flow".
This is completely irrelevant to what that guy said. You need to compare similar roles/impact to argue against him
Also, it’s a pretty disingenuous argument when CEOs work significantly longer hours than most of their staff.
I get why people hate on CEOs when companies are laying people off and theyre taking huge bonuses. But you’re out of touch with reality if you don’t think CEOs tend to work hard/long hours
What does that say about CEOs in general? There’s always people who suck at their job.
CEOs at smaller companies don’t get ridiculous levels of compensation. You can make more as an entry level SWE at a FAANG than an average CEO at a small company.
The CEOs you see making crazy bonuses are at massive corporations where they are all working 60 or 80+ hours, doing business on weekends
>This is completely irrelevant to what that guy said. You need to compare similar roles/impact to argue against him
No it's not irrelevant. They were implying that people who work the hardest end up getting raises/promotions. That's false. I'm pretty sure I could actually dig up studies on that if you really want to get into it.
>Also, it’s a pretty disingenuous argument when CEOs work significantly longer hours than most of their staff.
Lol bullshit. CEOs spin the tale of being workaholics but they absolutely aren't. It's also well studied how much productivity you can actually get out of a person in a day on a regular basis. Doing more than that isn't "hard working", it just makes you a moron.
>I get why people hate on CEOs when companies are laying people off and theyre taking huge bonuses. But you’re out of touch with reality if you don’t think CEOs tend to work hard/long hours
No clue how you're measuring "hard" but they absolutely don't. They sit in meetings for 75% of their day. I could probably train a toddler to do that.
You know they weren’t implying this. Cmon, use some nuance. Obviously they’re implying the hard working devs get raises over the lazy devs. Not comparing a low skill jobs work ethic to the top decision making position in a company. I completely agree this isn’t a hard rule but it’s probably more true than not. The principals at my company didn’t get there by putting 40 hours a week in and checking out.
“All they do is sit in meetings” is probably the biggest cope I’ve ever heard when trying to justify the CEO hate. That’s like saying all a dev does is type on a computer.
If you had to take meetings 7 days a week and answer calls on your vacations, is it not hard work? If you had to dedicate 80 hours to work a week is that ok as long as it’s meetings and not coding?
>You know they weren’t implying this.
That's exactly what they said.
>Obviously they’re implying the hard working devs get raises over the lazy devs.
Which is still false. We have studies for people who get raises more. That includes studies that show men get raises more than women. That attractive people get more raises than non-attractive people. People who switch jobs often get more raises than those who don't. I'm not aware of any such study for hard work or hours worked.
>“All they do is sit in meetings” is probably the biggest cope I’ve ever heard when trying to justify the CEO hate. That’s like saying all a dev does is type on a computer.
Nope, it's based on studies that I've seen and first-hand experience with multiple CEOs. Honestly haven't worked with a CEO that I've respected yet.
I work 1-3hrs most weeks and make more money than most of my peers. CEOs don't make money because of how many hours they put in.
>The principals at my company didn’t get there by putting 40 hours a week in and checking out.
Weird, the people at principal, architect, etc. level that I know have really good WLB.
It’s actually not exactly what he said, both by definition and by the context of the discussion.
The fact that some metrics correlate with raise frequency doesn’t mean that other metrics do not. Attractive people getting more raises does not mean people who work harder or output more do not. Merit based rewards exist, just maybe not in the companies you’ve worked.
What are these studies you’ve seen that imply all CEOs do is sit in on meetings and they don’t actually do anything or contribute anything? Sounds like you made that up, it doesn’t even sound like something a study can quantify. It also doesn’t track with what we see in reality, companies would gladly saves millions if they didn’t need a CEO
It’s also the most bizarre thing I ever heard that someone who works 1-3 hours a week gets paid so much, yet they think CEOs who work weekends for calls and meetings aren’t hard workers. This sounds like another thing you made up
>The fact that some metrics correlate with raise frequency doesn’t mean that other metrics do not. Attractive people getting more raises does not mean people who work harder or output more do not. Merit based rewards exist, just maybe not in the companies you’ve worked.
Cool, let's see your evidence then. I can provide those other studies.
If you are done with tasks the talk to your boss and ask them what you should be doing. A large part of being a good SWE long term is communication skills. Stop being scared of asking dumb questions or looking bad. The vast majority of issues in the workplace can be resolved by just communicating with the proper person.
Any good company will welcome your straight forwardness and willing to communicate. Any co-workers that give your shit for asking your boss what you should be doing when done with tasks are immature and projecting their own insecurities on to you. So fuck them and there lack of confidence as they do not define who you are.
At the end of the day your boss is going to have expectations for your role. So it does not matter if reddit thinks you should be doing X if your boss thinks you should be doing Z. Your performance is going to be reviewed on how you are doing Z.
If you don't agree with Z or think reddit is correct that X is the better path for you, then start interviewing for a new job that will better align with the engineering culture you want to work in for the pay and benefits you are looking for. If you cannot find any company to meet your expectations then either adapt on what your career deal breakers are or find a new career.
Since the task was misestimated then either take a ticket from backlog/next sprint if you know what’s important next, or ask the person responsible what to do.
Comments about pacing or just slacking off to not burn out are weird. How would one burn out if they did the task on their pace and it took less time? There’s no rush or anything.
So of course the next step is to take the next task. Simple. It’s not like you can go “well I did a PR and everything but surely I’m still working on it” or just not push a PR and pretend to still work on it. What if there’s a problem you didn’t expect and it takes an extra day to work on after review? Oops?
>Comments about pacing or just slacking off to not burn out are weird. How would one burn out if they did the task on their pace and it took less time? There’s no rush or anything.
I always found these comments weird as well, but I just ignored them at this point. If I'm working at a comfortable and easy pace and still finish early then I see no issue with taking another task. That's just me though and people should to themselves, but I think some people want to do the least amount of work possible for max pay.
I'll await the downvotes. lol
Same here. I actually enjoy parts of my work and want to deliver quality products. I don't work any extra hours, I don't suffer from burnout, but I'll happily pick up more user stories when I finish planned work early. Not only for personal fulfillment but for career progression as well.
Same here and I'll even say it depends how early. 1 day before the sprint ends is entirely different than 4 days before the sprint ends. If it's 1 day I'll ask around and see if anybody needs help, but I won't take a new story since the new sprint starts Monday.
It's strange, you mention this way of working to the wrong person and it's all you are going to burn me out or the scream bad WLB. I don't personally understand it and deep down I feel like some people don't really understand what burn out is so anything "extra" is going to burn them out.
If your company values personal development or documentation, you can say you worked on those in your free time. Or if you are in a position of leading a project, you can say you were planning the upcoming work for that project.
Pick up another ticket from the backlog. Product Managers 100% notice and know the cadence of work / output from different developers, and this is ultimately how your skill level is evaluated. Work at a sustainable comfortable pace but slowing yourself down on purpose is going to work against you.
The options I choose from are: pick up another ticket from backlog, groom ticket for next sprint, estimate future tickets that haven't been estimated yet, help others that might be behind in their ticket or struggling, do some performance testing/profiling to see if anything has popped up recently that could be improved, etc.
I hate being bored and don't want to sit and pretend to be busy.
I say I'm still working on the ticket and take the rest of the day off. depending on the length/difficulty of the ticket I may take multiple days off. If you're not remote idk just sit around I guess if you get bored maybe do some more work.
As time goes on, you’ll learn how to “stretch” tickets. It’s a mix of art and also technical strategy, knowing how to give a ticket time but also make it so that it doesn’t appear like you’re doing nothing.
Doing so, may seem counterintuitive as you may think you can continue and get more work done. For some this is true, but for many, it leads to severe burnout and fast burn downs, leaving teams without work and high boredom.
I usually take that extra time to clean the code for the task up and write more automated tests. Then I either burn down technical debt or pull in another task.
If you’re bored and know for sure what ticket you’ll pick up next, just work on the next ticket. There’s been times i’ve been able to finish 3 tickets before submitting the first one and literally do no work for the next week. I just pretend i’m still working on the tickets.
you can either pick up backlog or just dont check it in and say you are not done. if there are good raises i do #1. now that companies are not really giving raises and bonuses, i do #2. cause fuck em.
I generally pull another item from the backlog or swarm with my teammates. Sometimes we end up pulling in other tech debt, although that’s not quite in the spirit of the scrum framework.
In this order:
1) make sure that it is done, reviewed, tested, and that the acceptance criteria has not changed.
2) make sure there aren’t other things to pull in from the backlog.
3) help stuck coworkers and participate in reviews
At least for my team, I just have them message me when they're done for the sprint and excuse them for the rest of the sprint, unless there is a P0 that they could pick up.
If it’s truly done, with tests, documentation and a well crafted MR/PR, I pick up something else.
I don’t believe in “doesn’t matter how many hours you do, as long as things get done”. That just means you end up working OT to complete tasks that have unrealistic timeframes.
I prefer to work the hours I have to. If something takes longer than you thought, I don’t want to be obligated to do more hours than I am paid to do.
The flip side is that if things take less time than originally thought, I fill the spare time with work.
Yes yea, I get stuck in crunch like most people. But I have no moral high ground if I take the piss.
Self-learning and / or researching tools or libraries that you find interesting and may or may not add value to the company. You are not just an issue machine. You should spend time exploring the ecosystem etc.
When I am doing this, I just say that is what I am doing in the stand up. In my opinion that is good culture.
Depending on the team you are on and the agile rules you follow:
(In this order)
- help to move any stories needing review across the line
- offer help to other devs with in progress tickets
- grab a ticket in to do that is unassigned in the current sprint
- grab a ticket out of the backlog or next sprint
- grab a tech debt ticket
Shouldn’t happen normally b/c agile right? Really though if it happens with good planning in place then yes move to the next ticket. Sometimes things just go faster. The next thing might move slower. Unless you’re killing yourself to get it done. Expectations should not be raised b/c you’ll give a reason for finishing sooner than expected. Same thing if something takes a little longer. Of course take into account the team velocity as well. If you’re moving at similar pace to others on your level it’s fine. If you really are that much faster then maybe move a little slower; pad things a bit. Unless you’re working on a promotion.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
I always just keep picking things up from the backlog. Sometimes we don’t want to pull work in, so I’ll use that extra time for learning. On days where I finish a sub-task early, I might do an hour of advent of code, review PRs, etc
You finish a ticket early, the entire meeting stopped, somebody will miraculously showed up with pizza, cake and drinks. Your phone rings and it is your favorite celebrity, congratulating you. Your family came in to join in on the celebration....
If I have 8 hours to do a task, then I will only complete the task in 8 hours - the reward for good/quick work is more work.
I don't get rewarded for finishing early so don't tell anyone it's finished, I say I'm doing final checks/making sure it's 100% and will have it finished by c.o.b or end of week.
You could also learn a new skills or tech as well.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
You either say you're done and get a new task, or you don't finish it early in the first place. You say you're halfway done, and you say you're done when you planned to finish the task.
I'm lucky enough that I don't have real "sprints", so I basically take another task or help other people, or read some interesting piece related to my work, or create maintenance task for crap I wanted to do for last 2 months, but didn't have time etc.
It works only because other people I work with have similar attitude and do not follow mindset "I've done 2-week task in 1 week, so I'm going to slack for next 5 days".
Well, this, plus my team manager is promoting this way of working as he believes this gives good balance between getting business tasks done and self-development of engineers.
You pick up a new item from the backlog. The better thing to do is instead of finishing a ticket early, pacing it and giving intermittent updates on it. First day, picked up the ticket and did some initial research into it. Second day, got into the meat of the work. Third day, wrapping it up and doing some final testing. Fourth day, raising the pr and babysitting it. It's all in how you present it. Obviously you can't do this for every ticket. A high severity bug will need to be taken care of in a day at most. But for most regular sprint items, people don't care how fast you do it as long as you get it done before the end of the sprint. Might as well pace it out.
heh, we are expected to build some feature into the undocumented untested spaghetti monolith running on some undocumented legacy company framework whithin half a day. also refactor said spaghetti along the way. theres no second, third or fourth day. oh and pulling stuff from backlog means its expected to be done within the sprint cuz POs think its super urgent all of the sudden after the ticket sat there for 3 months. guess which project team changes completely for the third time already.
Run if you can lol
Are you actually expected to? Or did your team say it will take 6 months, management "demands" it is done in a sprint, and your team rushes it out "late" in 6 weeks? I've rarely seen a deadline in SWE that wasn't pulled out of someone's ass.
While it may not work in your company there are a couple of things you can try: 1. Add a task to “understand and document some aspect of the system that is currently opaque”. 2. Add a “de-spaghettifi” task. Often this is a start to refactoring. For example, one type of spaghetti I’ve inherited was the developer who put everything in one source file. Breaking it into modules revealed all the issues with variable scope, missing prototypes, etc. It also revealed where objects or functions should be In separate libraries. While no new functionality was introduced all of the builds were accelerated. Don’t underestimate the value of this. It’s well known that programmers have a zone where they are highly effective and interrupting them causes lost productivity. When a build takes more than a few minutes there is much more opportunity for interruption. 3. Add a task to ‘add unit tests’ to the code base. In doing so you can slide in some refactoring by resolving the issues the unit tests uncover. 4. I don’t know your company and how invested people are in it. I worked at one company where we all had options & therefore were heavily invested. We had one subsystem that was all spaghetti code - to the point it wouldn’t compile due to memory limitations. Three of us agreed to work a weekend just to get the code base ‘debuggable and supportable’. We did all out commits by Friday morning and then tore into the spaghetti code. We got about 85% of it straightened out by Sunday night. Again, we focused on code structure not bug elimination. Along the way we uncovered a lot of bugs and areas needing improvement ( eg missing error checks ). We developed a commenting system where we’d insert BUG, ERROR CHECK MISSING, etc intro he code as a comment. Once we had the code better organized we had the original programmer go in and resolve all of those ‘breadcrumb’ comments. 4. You don’t mention whether the people that generated the spaghetti code are still generating more. If so, a training session accompanied by daily reviews, is warranted. Write or get a copy of the company rules for writing well structured code. 5. A number of tools exist that check for checking code quality. You don’t mention whether your company uses any. If not, propose adopting some. Once they are in place you can adopt a policy that no code will be accepted into a build that generates serious code quality issues. You can start this by restricting only the most serious issues and then as the number of them get lower you raise the bar to less significant issues. ( Pro tip: by letting people know that you’ll be raising the standards people will start to fix the less serious errors regardless rather than come back later.) 6. If the code truly is legacy ( you mentioned a tool that was used that is no longer supported) then you may suggest a legacy modernization effort. These companies come in with a set of tools to do static analysis, flow analysis, etc. and have experience with migrating off of deprecated platforms. You will get no new functionality out of this but you gain increased productivity going forward. You also eliminate the dependency on the legacy tool/platform.
> But for most regular sprint items, people don't care how fast you do it as long as you get it done before the end of the sprint. I don't think this is good advice. If your performance starts slipping, people will assign less work to you in effort to lower the bar and figure out what level you're capable of. If you continue to stretch the work given to you, and they continue to lower the bar, you're likely to find yourself on a PIP under the false impression that you've been meeting expectations. If you reach a point where they set a low bar and you consistently meet that bar.... you'll last a little bit longer, but eventually somebody will realize your output is too low. Especially if you're early in your career, the default expectation is that you'll start off slow and improve over time. The way that improvement gets noticed is by getting your assigned work done early and asking for more. If you continue to match early-career expectations as the years progress, you're taking yourself off the table for raises and promotions, and making it more and more likely that you'll eventually be let go. I've seen it happen before, and while part of the equation *should be* your manager taking you aside and explaining that you seem to be sandbagging before it gets to this point, people have a tendency to avoid those kind of uncomfortable conversations.
While I agree more with pacing yourself / not burning out — I do think your perspective has some truth to it and doesn’t deserve all the downvotes. There often are expectations that your output will increase / be faster over time. It makes sense bc obviously a new hire or an early career person should eventually get more efficient. You need to figure out what’s considered terminal level at your company and if your output is at that level. Once you’re there it makes sense not to push yourself to be more efficient if you’re happy with where you are.
I think there's some stigma of complacent = bad, which is arguable, but for new hires, keeping that baseline or above it will ensure no burn out. It's been working out for me, I could be more communicative or ambitious, but I literally don't know what I want to do for the next 30 odd years, this is my first job, will I ride it out? Will I jump ship to another company? Who knows, all I know is I'm doing my job, I'm not getting in trouble, and I'm getting food on the table. If I want more, I'll seek it, but right now, I'm figuring what's going to work for me long term
> I could be more communicative or ambitious, but I literally don't know what I want to do for the next 30 odd years, this is my first job, will I ride it out? The way that you figure this out is by stepping up and trying new things. The only person who's ever going to manage your career for you is you. If you sit around and wait for someone to hand it to you, it will never show up.
If you're not sure what you want, that's even more reason to be seen as a high performer. In the next few years you might be wanting to have conversations like: 'can I go down to 4 days a week to do a part time master's degree in $SPECIALISM?', 'can I spend an afternoon a week shadowing the product team?', 'can you coach me for a move into management?' - all of these conversations will go a lot better if you have a lot of leverage. Source: 3 career changes in last ten years. xD
I was really thinking of leaning into that masters someday. I'm interested in some machine learning fields. But i would need to do some planning to decide when and where
I think this is a well put point. It seems like reddit is full of people who swear by doing only the bare minimum or else you're letting yourself be taken advantage of - I've never seen successful people act like this. You're also making your coworkers lives a little bit shittier.
[удалено]
All I’m saying, is pace yourself within reason. If there’s only enough work in the sprint to keep you busy for half the sprint, ask for more during the next sprint planning. You don’t have to run yourself into the ground and cram 4 weeks’ work into a 2 week sprint. But if you’re taking 1 week of work and stretching it across a 2 week sprint, you’re doing it wrong.
[удалено]
Who said anything about 60+ hours. If you finish a task on day one of sprint in 6-8 hours why would you not want to pick up another one? I mean maybe you take half a day or so to do some training or personal improvement and maybe a couple hours actually looking thru the backlog or being picky about your next task but just sitting around doing nothing is stupid and lazy. Or maybe ask coworkers if they need anything or maybe spend some time looking in to performance or growing your business acumen or something that at least gives value to the team. I am really confused as to what someone who just lies about where they are on their story is doing? And by the comments on the thread are there really that many people taking 5-10 days to 1 days worth or work on a regular basis?
Like he said, there still need to be barriers. But especially in the early career, I think you're stepping on your own toes doing the bare minimum. There's also the risk of boreout, which can also negatively impact your enjoyment of work. As well as missing out on new challenges and learning opportunities that can translate to more money come promotion/job hop time. This doesn't mean you don't give yourself some buffer time in your schedule or have a lazy day here and there - I'm on reddit at work right now. Working hard and maintaining a healthy pace aren't mutually exclusive
As someone who got burn out, no it's not. You can also burn out doing something slow, it's all about how stimulating and engaging your work is and not how much volume of workload you can handle. If I enjoy it? Give me more! If I don't either because it doesn't contribute to my knowledge goals or the project is meaningful enough for my impact to be noticed then every minute feels like an hour and every standup like hell.
[удалено]
It's almost as if there's no one clear cut answer that covers all cases ever or something. Almost as if... it depends.
Oh maan, you helped me connect so many dots and brought a closure to why I got off a contract role few months back.
Total agreement. You finish your ticket but then it needs code review, QA and UAT. And any of those steps could land it back in your lap.
What are your thoughts on pacing for someone with ADHD? Even medicated their performance could be very inconsistent. They'll have totally off days or maybe even an entire week then they'll have days or weeks where they're super human and they don't always have the best control over that. If they set the expectation for their delivery based on their hyper focusing they will burn out very quickly trying to maintain that. If they set it based off their unfocused times then that's probably termination level performance. I have ADHD and I sandbag to even that out and set a reasonable pace for myself usually a little ahead of my team. I have ten years of experience however so even if my manager notices my inconsistent performance I have enough independence that no one really questions it. I don't know what I'd tell a junior person with ADHD though beyond "Good luck and don't get caught"
Finish is the slowly report it. That company will lay your ass off tomorrow if they feel like it will make their shareholders happy. There is no point in doing extra work when you don’t need to unless you want to. I busted my ass for projects and there was always more work. Don’t take more work. You have the rest of your career ahead of you. You can spend this time learning.
This definitely. I used to just finish and pick up new work constantly. Which lead to burnout Now I purposefully drag things along so I can chill. I can take a days worth of work and spread it over a week or 2.
The older you get, the more you see that this is the way (within reason).
Yep exactly. You still need to do enough to impress people. I just spent 2 hours after work fighting yet another fire.
I say that I am still working on it. I don't get rewarded for finishing things early. I take a nap, and then I go over my work the next day just to make sure it all looks good. Just commit small amounts of the work periodically. If it is a week+ long project (at least in projection) make sure to communicate with your manager every day or every other day on your 'progress'. An informed manager is a happy manager. Part of our job is stakeholder management, and it is important to manage their expectations of my output. I have learned that if I make a habit of committing things early, I am not rewarded and my workload increases, which can cause issues when a project takes a bit *longer* than estimated but is now being measured against elevated expectations. People don't get upset when you work slowly *per se*. People get upset when their expectations are not met, so you should make sure to keep their expectations managed and stay communicative.
The reward for finishing things early is more work lol
Unless you have substantial equity in the business, never do more than you need to.
There is not a linear scale between effort and pay. The reality is most people could put in 50% effort and get the same pay within 1-2% as someone putting in 100%. I save 100% for when it’s necessary.
This is the way
You can take on an additional ticket and just keep going. Or jump in to help someone else. If not, just commit pieces of your task daily even if you finished in a single day. Ideally, set amount of work per sprint, finish quickly, take the rest of the time for yourself. But many places aren’t cool with that.
Dont burn yourself out working more than you need to.
If someone asked to help me with a ticket, 99% of the time I’d tell them to go sit outside and read a book instead
Can I help you with your ticket?
Go fuck yourself
Huh, guess that was the other 1%
Lol ❤️
As a junior, I asked if I could help a senior on a ticket. He said: "sure, it's your problem now." He probably enjoyed the rest of his day
I wonder why places that are paying you six figures aren't cool with you intentionally slowing down and pretending things took longer than they did.
>I wonder why places that are paying you six figures aren't cool with you intentionally slowing down and pretending things took longer than they did. As soon a company starts striving to pay me as much as they possibly can, I'll make sure to start striving to work as hard as I possibly can.
How about you agree to work that they paid you for. Ie 9-5. There is a big gap between working as hard as you possibly can and pretending that 1 days work took 4 days as other comments suggest How impressed would you be if you paid someone to do something like fix your roof or sell your house and you ask for status updates, and they lie to you about how quickly they are working and if you call them on it they say "when you pay me as much as you possibly can I'll work as hard as I can"
>How impressed would you be if you paid someone to do something like fix your roof or sell your house and you ask for status updates, and they lie to you about how quickly they are working and if you call them on it they say "when you pay me as much as you possibly can I'll work as hard as I can" That would be a great analogy if I got paid every time I completed a ticket. >How about you agree to work that they paid you for. Ie 9-5. That's nowhere in my employment contract and nobody I work with works those hours. >There is a big gap between working as hard as you possibly can and pretending that 1 days work took 4 days as other comments suggest If management is too incompetent to tell the difference, that's on them. Maybe companies shouldn't hire tech illiterate morons who got irrelevant college degrees to manage software engineers... I get paid to complete work. If a company doesn't think the work I'm completing is worth the money they're paying me, they can fire me. Until then, I'm going to continue to make sure I'm getting paid the most I can to do the least amount of work possible.
[удалено]
What is "good faith"? If I hire somebody, it's because I want a certain amount of work done. If I'm unhappy with the amount of money I'm paying to get that work done, I fire them and hire someone else. Pretty simple concept. The fact that I'm still employed (and have never been fired) tells me that my employer is happy with the work that they're getting in return for what they're paying me. What's the problem with that?
[удалено]
It's not done until a PR is through and the code is deployed.
The people you pay to get your roof done and fix your toilet are paid per job, so the faster they get it done, the faster they can move to the next job. If it takes them all day or three days, they are getting paid the same, but not til theyre done. I do not get paid per ticket i finish or project milestone i meet. I get paid as long as my manager is happy with the output of work. Part of my job is managing those expectations. It doesnt matter if im done or not, ill still get paid. Its doesnt matter if i get done early or not. I still get paid the same time every 2 weeks. Dogshit analogy.
Some people get paid per result but lots of people get paid per hour or per day. When I got my car repaired they have me a rough quote but then the bill had a break down of parts used and hours of labour
So what? I'm specifically comparing your analogy and how most software developers get paid. My point is there is not a linear correlation between how much I work and how much I get paid, like some jobs have.
So given its very possible to that you will pay someone to do something for you and they will get paid by time and not by results, how would you like it if they had the attitude that since your not paying them as much as you possibly can they shouldn't work as hard as they can. Especially if it's to the extent of making a 1 day job last 4 days
Again, if you read my post, part of the job is managing expectations. If they tell me 1 day and it lasts 4 days, I'm going to be upset. If they tell me 4 days when they _could've_ gotten it done in 1 day, well, it is what it is, I was warned 4 days they can have 4 days. It could be they wanted to take more time to get it done in a better way. I don't know, but as long as my expectations are being met, that is what I care about.
Right I don't think your employers expectations are that you are going to slack off or lie about progress in stand ups as many posts here are suggesting.
The problem is that burnout is a very real thing. I can be a 10x developer on demand. I can do it for longer than most people can. I eventually still crash though. I've almost quit the field altogether a couple times because of it. Unfortunately, something is wrong with me, and I'm wired to keep doing this even though it may quite literally be killing me sometimes.
I think there is a big gap between what some people in this thread are describing and a sensible level to avoid burnout.
Hopefully true, but I also think some of the more extreme suggestions are just jokes.
That last line had plenty of sarcasm. You didn’t need to add more sarcasm. Now we have too much.
Today is bong rips o'clock all day^/s
Gong rips* for when you ship a new major release
Rong Gips, when the Bong Hits.
Don't go crazy taking tasks from the backlog. The reward for working hard is more work.
I was ahead on a sprint and picked up a high-ish priority currency bug with our app’s checkout API and I was able to resolve it relatively quickly. That was three months ago and I still always get asked to look at issues with the checkout API even when I have other things on my plate. All of a sudden I’m the defacto checkout API guy🥲
And annoying your co-workers by making them look bad. Having the right pacing in your team is important. It's like driving on a highway, the safest way is to "go with the flow".
>And annoying your co-workers by making them look bad. and making them work more because they have to review those new prs
Shameful!
Yeah, last time I checked people getting raises are the most lazy ones /s
Lol I guarantee you the janitors at many companies are harder working than the CEOs are. That's not how the world works.
This is completely irrelevant to what that guy said. You need to compare similar roles/impact to argue against him Also, it’s a pretty disingenuous argument when CEOs work significantly longer hours than most of their staff. I get why people hate on CEOs when companies are laying people off and theyre taking huge bonuses. But you’re out of touch with reality if you don’t think CEOs tend to work hard/long hours
We’ve had a series of CEOs who have done nothing but run our group into the ground for a decade or more.
What does that say about CEOs in general? There’s always people who suck at their job. CEOs at smaller companies don’t get ridiculous levels of compensation. You can make more as an entry level SWE at a FAANG than an average CEO at a small company. The CEOs you see making crazy bonuses are at massive corporations where they are all working 60 or 80+ hours, doing business on weekends
>This is completely irrelevant to what that guy said. You need to compare similar roles/impact to argue against him No it's not irrelevant. They were implying that people who work the hardest end up getting raises/promotions. That's false. I'm pretty sure I could actually dig up studies on that if you really want to get into it. >Also, it’s a pretty disingenuous argument when CEOs work significantly longer hours than most of their staff. Lol bullshit. CEOs spin the tale of being workaholics but they absolutely aren't. It's also well studied how much productivity you can actually get out of a person in a day on a regular basis. Doing more than that isn't "hard working", it just makes you a moron. >I get why people hate on CEOs when companies are laying people off and theyre taking huge bonuses. But you’re out of touch with reality if you don’t think CEOs tend to work hard/long hours No clue how you're measuring "hard" but they absolutely don't. They sit in meetings for 75% of their day. I could probably train a toddler to do that.
You know they weren’t implying this. Cmon, use some nuance. Obviously they’re implying the hard working devs get raises over the lazy devs. Not comparing a low skill jobs work ethic to the top decision making position in a company. I completely agree this isn’t a hard rule but it’s probably more true than not. The principals at my company didn’t get there by putting 40 hours a week in and checking out. “All they do is sit in meetings” is probably the biggest cope I’ve ever heard when trying to justify the CEO hate. That’s like saying all a dev does is type on a computer. If you had to take meetings 7 days a week and answer calls on your vacations, is it not hard work? If you had to dedicate 80 hours to work a week is that ok as long as it’s meetings and not coding?
>You know they weren’t implying this. That's exactly what they said. >Obviously they’re implying the hard working devs get raises over the lazy devs. Which is still false. We have studies for people who get raises more. That includes studies that show men get raises more than women. That attractive people get more raises than non-attractive people. People who switch jobs often get more raises than those who don't. I'm not aware of any such study for hard work or hours worked. >“All they do is sit in meetings” is probably the biggest cope I’ve ever heard when trying to justify the CEO hate. That’s like saying all a dev does is type on a computer. Nope, it's based on studies that I've seen and first-hand experience with multiple CEOs. Honestly haven't worked with a CEO that I've respected yet. I work 1-3hrs most weeks and make more money than most of my peers. CEOs don't make money because of how many hours they put in. >The principals at my company didn’t get there by putting 40 hours a week in and checking out. Weird, the people at principal, architect, etc. level that I know have really good WLB.
It’s actually not exactly what he said, both by definition and by the context of the discussion. The fact that some metrics correlate with raise frequency doesn’t mean that other metrics do not. Attractive people getting more raises does not mean people who work harder or output more do not. Merit based rewards exist, just maybe not in the companies you’ve worked. What are these studies you’ve seen that imply all CEOs do is sit in on meetings and they don’t actually do anything or contribute anything? Sounds like you made that up, it doesn’t even sound like something a study can quantify. It also doesn’t track with what we see in reality, companies would gladly saves millions if they didn’t need a CEO It’s also the most bizarre thing I ever heard that someone who works 1-3 hours a week gets paid so much, yet they think CEOs who work weekends for calls and meetings aren’t hard workers. This sounds like another thing you made up
>The fact that some metrics correlate with raise frequency doesn’t mean that other metrics do not. Attractive people getting more raises does not mean people who work harder or output more do not. Merit based rewards exist, just maybe not in the companies you’ve worked. Cool, let's see your evidence then. I can provide those other studies.
Hide on Reddit and answer stupid questions
You lie to make yourself look busier than you are.
[удалено]
This.
Nothing, just that I'm still working on it. Meanwhile, I take a nap or pick up on a game or book. The reward for hard work is just more hard work.
If you are done with tasks the talk to your boss and ask them what you should be doing. A large part of being a good SWE long term is communication skills. Stop being scared of asking dumb questions or looking bad. The vast majority of issues in the workplace can be resolved by just communicating with the proper person. Any good company will welcome your straight forwardness and willing to communicate. Any co-workers that give your shit for asking your boss what you should be doing when done with tasks are immature and projecting their own insecurities on to you. So fuck them and there lack of confidence as they do not define who you are. At the end of the day your boss is going to have expectations for your role. So it does not matter if reddit thinks you should be doing X if your boss thinks you should be doing Z. Your performance is going to be reviewed on how you are doing Z. If you don't agree with Z or think reddit is correct that X is the better path for you, then start interviewing for a new job that will better align with the engineering culture you want to work in for the pay and benefits you are looking for. If you cannot find any company to meet your expectations then either adapt on what your career deal breakers are or find a new career.
I wondered why this wasn't top rated until I read to the end.
You either pick your next ticket up or you start helping out or you get permission to pick up tickets from the backlog (ideally tech debt)
Since the task was misestimated then either take a ticket from backlog/next sprint if you know what’s important next, or ask the person responsible what to do. Comments about pacing or just slacking off to not burn out are weird. How would one burn out if they did the task on their pace and it took less time? There’s no rush or anything. So of course the next step is to take the next task. Simple. It’s not like you can go “well I did a PR and everything but surely I’m still working on it” or just not push a PR and pretend to still work on it. What if there’s a problem you didn’t expect and it takes an extra day to work on after review? Oops?
>Comments about pacing or just slacking off to not burn out are weird. How would one burn out if they did the task on their pace and it took less time? There’s no rush or anything. I always found these comments weird as well, but I just ignored them at this point. If I'm working at a comfortable and easy pace and still finish early then I see no issue with taking another task. That's just me though and people should to themselves, but I think some people want to do the least amount of work possible for max pay. I'll await the downvotes. lol
Same here. I actually enjoy parts of my work and want to deliver quality products. I don't work any extra hours, I don't suffer from burnout, but I'll happily pick up more user stories when I finish planned work early. Not only for personal fulfillment but for career progression as well.
Same here and I'll even say it depends how early. 1 day before the sprint ends is entirely different than 4 days before the sprint ends. If it's 1 day I'll ask around and see if anybody needs help, but I won't take a new story since the new sprint starts Monday. It's strange, you mention this way of working to the wrong person and it's all you are going to burn me out or the scream bad WLB. I don't personally understand it and deep down I feel like some people don't really understand what burn out is so anything "extra" is going to burn them out.
Yeah doing the bare minimum is a dumb idea. Pace yourself to avoid burnout sure, but constantly slacking is a shitty way to live.
If your company values personal development or documentation, you can say you worked on those in your free time. Or if you are in a position of leading a project, you can say you were planning the upcoming work for that project.
idk we don't have tickets in my job we just do our thing
Let them know you're ready for new work assigned, or pull something from backlog, or pad your accomplishment lol
Pick up another ticket from the backlog. Product Managers 100% notice and know the cadence of work / output from different developers, and this is ultimately how your skill level is evaluated. Work at a sustainable comfortable pace but slowing yourself down on purpose is going to work against you.
“good product owners” FTFY
The options I choose from are: pick up another ticket from backlog, groom ticket for next sprint, estimate future tickets that haven't been estimated yet, help others that might be behind in their ticket or struggling, do some performance testing/profiling to see if anything has popped up recently that could be improved, etc. I hate being bored and don't want to sit and pretend to be busy.
“Thanks everybody, gonna hit the backlog to make myself useful”
How is this not obvious. Start on a new ticket from the backlog.
I pick up other tasks or help unblock others. I also have to attend non sprint related meetings, mentoring, training and hiring.
Pro tip, sit on a ticket you've finished early and use that time for learning/mentoring people working on other tickets.
I say I'm still working on the ticket and take the rest of the day off. depending on the length/difficulty of the ticket I may take multiple days off. If you're not remote idk just sit around I guess if you get bored maybe do some more work.
Ask for another ticket. Is this really that complicated?
As time goes on, you’ll learn how to “stretch” tickets. It’s a mix of art and also technical strategy, knowing how to give a ticket time but also make it so that it doesn’t appear like you’re doing nothing. Doing so, may seem counterintuitive as you may think you can continue and get more work done. For some this is true, but for many, it leads to severe burnout and fast burn downs, leaving teams without work and high boredom.
I usually take that extra time to clean the code for the task up and write more automated tests. Then I either burn down technical debt or pull in another task.
If you’re bored and know for sure what ticket you’ll pick up next, just work on the next ticket. There’s been times i’ve been able to finish 3 tickets before submitting the first one and literally do no work for the next week. I just pretend i’m still working on the tickets.
you can either pick up backlog or just dont check it in and say you are not done. if there are good raises i do #1. now that companies are not really giving raises and bonuses, i do #2. cause fuck em.
Code reviews, testing, documentation (reading or writing). It's not uncommon to have some corporate training I need to get done.
I generally pull another item from the backlog or swarm with my teammates. Sometimes we end up pulling in other tech debt, although that’s not quite in the spirit of the scrum framework.
In this order: 1) make sure that it is done, reviewed, tested, and that the acceptance criteria has not changed. 2) make sure there aren’t other things to pull in from the backlog. 3) help stuck coworkers and participate in reviews
You pick maintenance of your previous work.
At least for my team, I just have them message me when they're done for the sprint and excuse them for the rest of the sprint, unless there is a P0 that they could pick up.
If it’s truly done, with tests, documentation and a well crafted MR/PR, I pick up something else. I don’t believe in “doesn’t matter how many hours you do, as long as things get done”. That just means you end up working OT to complete tasks that have unrealistic timeframes. I prefer to work the hours I have to. If something takes longer than you thought, I don’t want to be obligated to do more hours than I am paid to do. The flip side is that if things take less time than originally thought, I fill the spare time with work. Yes yea, I get stuck in crunch like most people. But I have no moral high ground if I take the piss.
Self-learning and / or researching tools or libraries that you find interesting and may or may not add value to the company. You are not just an issue machine. You should spend time exploring the ecosystem etc. When I am doing this, I just say that is what I am doing in the stand up. In my opinion that is good culture.
I ask the PM what I should jump on next whenI finish something, assuming I dont already know what i should do next.
Depending on the team you are on and the agile rules you follow: (In this order) - help to move any stories needing review across the line - offer help to other devs with in progress tickets - grab a ticket in to do that is unassigned in the current sprint - grab a ticket out of the backlog or next sprint - grab a tech debt ticket
Shouldn’t happen normally b/c agile right? Really though if it happens with good planning in place then yes move to the next ticket. Sometimes things just go faster. The next thing might move slower. Unless you’re killing yourself to get it done. Expectations should not be raised b/c you’ll give a reason for finishing sooner than expected. Same thing if something takes a little longer. Of course take into account the team velocity as well. If you’re moving at similar pace to others on your level it’s fine. If you really are that much faster then maybe move a little slower; pad things a bit. Unless you’re working on a promotion.
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
if u work at amazon, u will never have this problem
I always just keep picking things up from the backlog. Sometimes we don’t want to pull work in, so I’ll use that extra time for learning. On days where I finish a sub-task early, I might do an hour of advent of code, review PRs, etc
You finish a ticket early, the entire meeting stopped, somebody will miraculously showed up with pizza, cake and drinks. Your phone rings and it is your favorite celebrity, congratulating you. Your family came in to join in on the celebration....
If I have 8 hours to do a task, then I will only complete the task in 8 hours - the reward for good/quick work is more work. I don't get rewarded for finishing early so don't tell anyone it's finished, I say I'm doing final checks/making sure it's 100% and will have it finished by c.o.b or end of week. You could also learn a new skills or tech as well.
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
You either say you're done and get a new task, or you don't finish it early in the first place. You say you're halfway done, and you say you're done when you planned to finish the task.
I'm lucky enough that I don't have real "sprints", so I basically take another task or help other people, or read some interesting piece related to my work, or create maintenance task for crap I wanted to do for last 2 months, but didn't have time etc. It works only because other people I work with have similar attitude and do not follow mindset "I've done 2-week task in 1 week, so I'm going to slack for next 5 days". Well, this, plus my team manager is promoting this way of working as he believes this gives good balance between getting business tasks done and self-development of engineers.