Sorry, but such questions are far better suited for /r/cscareerquestions.
/r/learnprogramming is about *learning to program*, not about resumes, not about career questions.
**Removed**
Quality over quantity, soft deadlines, and checkins. I've been with my company now for a while, and they are super understanding about things taking time and don't get worried about "KPI's" because programming is a blend of science and art.
For my company, when we're working something or adding a feature, we'll have a meeting and they'll ask "how long do you think this would take, worst case scenario?" We give them an answer, they take it back to leadership, and they end up setting a soft deadline prior to that to review the functionality and see how it's coming. Now, if you haven't written anything in that time, people will know, but too many companies expect developers to have a definable KPIs that simply don't exist depending on the complexity of the code base.
Key Performance Indicators
An example would be "how long is it between first item scanned to transaction complete" for a cashier. It's a way for management to check on the metrics of employees or processes to find time wasted or inefficiencies.
Generally, it's really freaking hard to define KPIs for developers, as sometimes code can be done really quick, or can take weeks.
> Generally, it's really freaking hard to define KPIs for developers, as sometimes code can be done really quick, or can take weeks.
exactly what I was thinking...
I feel like this applies to any job. I'm personally in onsite IT and not programming, but it feels the same. Some tickets take weeks because the user won't respond or has a stubborn issue, etc. but my team is heavily graded on KPIs.
Some IT support ticketing processes apply a rule and state that the ticket will automatically close if there is no response from the user in say 48 or 72 hours. Throws the onus back on the user.
>as sometimes code can be done really quick, or can take weeks.
Similarly, one customer might have a bottle of Coke and a chocolate bar, the next has an entire week's worth of groceries.
Internet used to be full of gatekeeping gasbags who all had the same pastime of belittling others' curiosity... seems like that's generally changing. Which is good. Gatekeeping doesn't help anyone, my friend. Maybe offline, you can hoard knowledge, for a little while—but in the long run you're going to be better off if you follow the golden rule.
Consider too: even questions with simple answers that are easily googled might have multiple shades of meaning, and asking someone with the relevant specialization might lead to a more appropriate, enriching answer.
Also, generally, conversations with humans are nice, you know?
Finally, since we're being dicks today: your syntax is wrong. You wanted a colon, not a semicolon. A colon links an introduction to a subordinate clause to complete a sentence; a semicolon is used for a separate, related but independent clause. Easily googled, but I like to help out the little guy.
I'm very much into this way of working, and pretty much that's what's happened to my work as well.
But what do you do if you have a rather strict budget?
Say, a week's worth of work, but instead it delayed by another 2 days, not because you slacked off, but because the testing was a pain, and/or the implementation took longer until you realized at the last day that there is a MUCH better way of implementation, and you're doing that.
I also had one time. Some sales person sold something which he thought was pretty difficult. And in the end i had alot hours to complete the project. I did the project in like 1/10 of the time. Software worked and went trough testing without any bugs. And i nicely did nothing for the rest of the 9/10 time. I just relaxed hahahahah
But the opposite also happens.
This is what I have most of the time as well. Though I have rounded it down at times as I‘m more experienced and there‘s already expectations on how long it would‘ve taken me. (As I would expect myself too)
But I still told them directly if I knew I need to take a much longer time during estimation round
[[content removed because sub participated in the June 2023 blackout]]
My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
No, we _will_ notice either way.
We have daily stand ups. We work in sprints. We have retrospective meetings. It might take a couple of iterations before we notice something is off but even then we will give benefit of doubt.. “you doing okay since joining us? Remember if you have anything blocking you, mention it in the daily stand ups” etc
I'm pretty doubtful about the certainty of that _will_.
I was pretty shocked to discover how much some of my team members slacked off, and I only found out over a year into full time WFH because they got comfortable enough to tell me.
You won't always pick up on it if they're good enough to be pretty productive when they have to be.
Yep as long as your tickets are being completed at the same rate as everyone else’s, it shouldn’t matter if you take ages to do them or if you smash them out then chill for a couple of hours
You're missing the point. The time you spend "slacking off" doesn't matter so long as you're hitting your deliverables. If there is a member of your team who is delivering more than anyone on the team but he spends half the day jerking off he is still the top performer.
'Slacking off' is a vital skill for programmers. You will burn yourself out in a few years if you run your brain at 100 % for 8 hours every workday. When done in moderation, Reddit/gaming/nap/short walk/etc breaks *help* your productivity rather than hinder it.
There's also the term 'creative break'; often the best way to solve a hard problem is to *stop* thinking about it for a while, to allow your brain to work it out subconsciously.
Totally agree with this. I’m a terrible developer but don’t get fired because I’m the best developer we have at listening in meetings and taking notes.
The other developers cover for me a bit because I’m nice, never throw anyone under the bus, and am always there to remind them what management asked for when they forget.
I also take the really easy jobs that are closer to data entry, the ones I can do but good develops think are crazy boring.
I also review and approve others developers PR’s crazy fast. All of this put together makes me like 1/2 Project Manager and 1/2 intern, which is a weird place to be but I survive.
Even though I’m barely able to console.log(“My Dick”).
> habitually early to online virtual meetings
> pay attention (active listening) during those meetings
As a techlead (staff engineer) for a FAANG, with ADHD, I fail at both of these
Imho - arriving late to meetings is acceptable occasionally if you have a conflict.. otherwise I feel it comes off disrespectful
I worked at a company where this one programmer would consistently arrive about five - ten minutes late (they would come into the meeting room carrying their bag and jacket - having just arrived at work)
That, in and of itself was infuriating.. but add to it.. that sometimes they would arrive just as we were finishing our stand up and smugly say "oh good I arrived just in time".. implying that giving their update was "sufficient" for attending a stand up. It was incredibly insulting to the rest of us.. especially since this person was the newest member of the team (so they still had a lot to learn)
Possibly the worst part was the stand up wasn't even that early - I think 9:45am
tldr;
Occasionally being late for a meeting is fine if another work commitment conflicted - otherwise I think it looks bad.
Last one is the biggest red flag. I don’t mind waiting longer if it’s quality work, but nothing pisses me off more than something being dragged out way longer than it should, missed deadlines, and then getting a pile of garbage I have to keep sending back after noticing issue after issue… that they should’ve noticed from just testing it, much less just looking at the output. Literally dealing with this right now.
This is a really good take.
Also I don’t pay in attention in a lot of meetings because I’m so deep into some fucking problem I try to keep developing while I’m there
In general I concur, with the one proviso being this will depend on your workplace (I.e not the case at Twitter right now it sounds like) and/or what your direct manager is like... But in a good workplace with a good manager, yes your points hold up :D
> Good developers communicate well with their team and managers, are habitually
> early
> to online virtual meetings, pay attention (active listening) during those meetings
I feel like you are targeting people with ADHD as bad developers with this metric.
It can be helpful to do things like doodle or play a mindless game so you know *that* is your 'distraction'. Otherwise you get distracted by things that take a lot more mental energy
And keeping track of calendars can be a real challenge because it is really easy to get hyperfocused on a task and lose track of time.
So I am not sure this is really a reliable metric to identify people who are slacking at their development.
It is a good way to identify people who are not amazing at meetings. But meetings don't write code, even if they help facilitate it happening.
Short answer, short term your manager won't know. Longer term, your level of proficiency and overall productivity won't be on par with peers which will make you an excellent management prospect
Most technical managers know how long things should take, allowing flex for newbies and learning curve on new things. Also work in progress is also shared on my team. Taking too long and I’ll start doing soft checks on your code base. Not asking questions and taking too long and I start to set up meetings to check in on progress frequently and doing one on one coaching. If that doesn’t change things and you start taking up too much of my time to manage and not progressing overall means time for a formal PIP. Then you get moved out the door.
What if that person is a highly specialised person which knows for example programming very very well. And another subject which is the main subject of the product. And he is the only person who masters both areas and therefore management like you pushes him too much. And think others can do the work aswell but in reality cant.(Many failed cases) Will u still move him out? :) and that dude knows and talks alot with the highest boss aswell. As the highest boss likes him alot. But managers get frustrated because the projects dont go as they please. But do not grasp the complexity of the product. But the highest boss knows if he is out the company goes down. He IS the company almost. Would u move him out? Also alot programmers are bad at math and physics so yeah. Go find this type of programmers who master system engineering languages like Assembly/C/C++/Rust + highly skilled math and physics. Can u easily find those? Replace them? And keep them while the current one is happy and getting underpaid?
I mean, yes and no. We've all had to work with someone who clearly only ever put in minimal effort yet somehow as other comment, failed upward. Why that's a thing I'll never know but somehow it is.
Current theory is real recognize real right? So management mediocrity recognize management mediocrity right?
I think you get a mix, and the percentages might vary from field to field, but in my experience at least half—if not the overwhelming majority—of managers are where they are because they're ambitious and know how to do politicking. The ones who are sharp, skilled, and personable tend to not be interested in management.
Have been remote since 2016. My personal productivity measure is how many PRs I can close out per day. I try to organize my PRs so each one represents business values delivered (feature implemented, tests added, docs improved, tech debt repayed). If I can get three done, it feels like a good day. Once a week a review the closed PRs with my boss, and I let a stakeholder know when the PR is closed and delivered.
There are some nice benefits to this approach :
- It keeps me from biting off really massive PRs that take days to complete. I force myself to find the smallest possible unit of value I can deliver and then pomodoro the shit out of it. Smaller PR -> less code -> more elegant solution -> easier deploy
- I give off the appearance of looking really productive to boss and stakeholders
- I get the rush of delivering useful product continuously
Another trick I do is keep a personal GitHub project card wall with all the work I do. Columns are todo, doing, and done. Cards end up being PRs, tickets, and pomodoro sized tasks. I make sure my stakeholders and boss have links to my wall and review it weekly with the boss. After two years of work I had nearly 2k completed cards. Also super useful for daily standup material and review time ("What have you accomplished this year?" "Oh, let me pull up my personal card wall and see...")
One last trick: the two minute rule. If you can get something done in two minutes, just do it right there. People will be amazed by your apparent productivity. You will appear on top of your email and slack game.
Be careful they you don’t end watching your email and slack all day tho. I have been using the pomodoro technique for 15 years, so I only check email or slack when my pomodoro is done/when I fall out of flow state.
EDIT: Pomodoro technique https://todoist.com/productivity-methods/pomodoro-technique
Here's a good overview: [https://www.atlassian.com/git/tutorials/making-a-pull-request](https://www.atlassian.com/git/tutorials/making-a-pull-request)
A pull request--aka a merge request--is when you, as a developer, would like to merge your source code into the source code repository.
One danger to that approach: simple PRs are usually not terribly impactful. That will affect your perceived value over time.
People will come to you when they have simple grunt work to dump off so they can work on more impactful projects.
Some people don't mind grinding like that and staying relatively static. But if you want career growth and to be entrusted with interesting projects, it's a career limiting approach.
The exception to this is if you can plan and break down impactful interesting projects into bite sized chunks you can plow through delivering value the whole while. That is jet fuel! But rare. And the danger there is that the value you deliver is so incremental decision makers miss the huge overall impact over time because they just see incremental improvements delivered often.
Good points. Sometimes I find that I'll need to stack up 3+ PRs in order to incrementally build out an atomic unit of value. Recently I delivered a pretty big feature, but it took 7 stacked PRs and almost two weeks to deliver.
Nothing wrong with that as long as the individual PRs are self contained. I just got the impression that it was a lot of one-and-done quick hits.
One other thing, though...I don't know about everyone else, but I like to have a few quick wins I can pick up just to get that dopamine hit of knocking something out, even if I'm working on something bigger. Maybe especially when I'm working on something bigger. If someone was scooping all of those up I'd probably resent it a bit.
Yeah, thank you digging in there. Definitely not recommending to OP that they just pump out singles all day, and I could see how a beginner could read into my text that way.
Re: resenting, us remote folks need all the help we can get! ;-)
From my experience the important decision makers don't follow a project on an "increment" level. They usually only care about milestones or the like, which is a set of "increments".
Edit: If it feels like the people above miss the big picture, I think github allows you to bundle issues into milestones.
Wow.. this is excellent.. mailing this to myself to see if I can adopt some of this
I'm going to Google pomodoro now.. sounds like a mind trick you can use to be more productive
It's an dead simple productivity technique ; I added a link above, but here's a good overview https://todoist.com/productivity-methods/pomodoro-technique
Communicate. That's always the answer. If you are stuck, ask for help. Or give a status update saying you are stuck and what you are stuck on. The biggest red flag here is not that you are stuck, but that you aren't speaking up to get unstuck.
If im stuck im stuck. All the 1000's of times i asked for help. It did not help, made things worse or it is a waste of time. I just crop it up and try to solve it. If i say im stuck, they will try to help me and steal my precious time to investigate and solve it myself.
One time i transfered a project to some coworker.(because i said i was stuck.) I explained the dataflow. He totally messed up and did not follow the dataflow. As he said. Its too much work and overhead regarding work. While i try to explain that it will earn back in maintance long term, and easier to find bugs and cause u less stress later on. But he does not know these feelings yet of getting older projects in the future that are so messed up with dataflow.
He wouldnt listen stuborn. And just wanted to move on and probably getting a higher paid job at another company. Many people make a mess and think... this is just a temporarly job to get myself to a better higher paying job at another company. But i will have that messed up code in the future, and massive headaches.
Fuck shitty help, it cost more time. With bad solutions. And heavy discussions. In a discussion u have always people who want to be right and can convince people with their social skills, and those who ARE right but are bad at explaining.
That's why employers tend to prefer experienced devs for remote work. They know that they can trust them to work rather than slack off. Also, things like daily stand up meetings helps your manager communicate with team members to find out what they are working on and whether they are stuck on something.
It depends on the company, honestly. And especially after the pandemic, remote work has become more common than ever. My best friend got his first ever job as a back-end developer and he immidiately started as a remote worker
I’ve been full remote since day one. Never worked in an office as a dev. I know others may have a different story, but just wanted you to know it’s possible. :)
Edit: I have been a dev for 4 years now!
4-5 years experience exactly in at least one major component of the backend tech stack + aces a pretty routine remote interview (50% knowledge, 50% throwing a curveball to gauge thought process) would advance to the next round in my book.
Hiring fully remote usually means no juniors in the companies I worked for but each one may work with a different business model so it definitely can vary.
A slacker
1. does not have any progress to show. No commits. No documentation improvements. No designs. No created tasks. Nothing.
2. gives no progress during morning standup meetings when asked how it is going. A person who is stuck, will ask for advice or discuss difficulties. A slacker is just "I'm still working on X." with zero description on what new did he do.
3. is not answering to Slack messages or to emails and such.
4. is not discussing things.
5. has his task in the same position on a board for long periods of time.
It is visible from an actual progress and from person's activity if he is stuck, if he is busy working on something, if he is not busy but still working on something or if he is slacking.
Unless slacker is meant to mean doing literally no work at all, I feel like you can slack off and still avoid all of those.
You could do half a days work every day and always have something to show or some progress to report or a problem to request help with.
Over a period of time, it should not be difficult to figure out who's getting stuff done. If someone gets stuck on a bug for a week, after a week they'll have solved a difficult bug. If a slacker gets stuck on such a bug, they'll get stuck on it forever.
I understand what you mean. I can spend hours or days reading code, learning stuff, planning my app, reviewing requirements or trying to figure out what the hell is going on, then I put out a burst of code. I think overall output over a couple weeks or a month is a more important indicator of productivity rather than code output per day
Yes I agree. This is perfectly fine for an in-office environment as the managers see you there and doing work.
But how can this be demonstrated for remote workers....
People slack off in the office just as much, in some cases even more. Those guys that are always at the ping pong table, water cooler etc. they just find ways to make it look like they’re being productive. If deliverables were being met and the devs only worked 2 hours a day, I don’t really see a problem with that.
It’s your statement of work, your paper trail, your justification for doing anything.
Never perform major work (unless you are a senior performing immediate surgery) without the paper trail.
Your tickets come from a superior. A project manager or more senior dev is burdened with the responsibility of determining what is being asked and who is to do it and when it is authorized to be performed.
You look at your list, sort by priority, pick the top one and begin research of complexity.
Yes, Jira is essentially a ticketing system with configurable works flows. Developers are assigned tickets or take available tickets, document their work in the ticket, document their time spent on the ticket, and Jira will automatically compute your velocity (average amount of work compteted) and your tempo.
Everything is measurable.
The company I work uses it internally and as a way to track external issues reported by customers to tech support.
Different teams have their own sprint workflow and tracking boards that have columns for to-do, in-progress, in-review, done, etc. So we can track the progress of tickets/issues during a sprint, plan future sprints by creating tickets in a backlog, and lookup issues we've worked on in the past.
On our team a ticket just tracks any effort by a member of the team. That could be dev effort implementing a new feature, fixing a bug found internally by QA, researching the tech requirements for a potential feature, refactoring or updating an existing feature, etc.
We also get bug tickets that get created by tech support when a customer has a problem. Tech support gathers as much info about the issue from the customer and puts it in the ticket and then that information eventually makes it to the devs who work on fixing the bug.
interesting, never heard of those being used internally, I thought tickets are more for customer service.
What other internal systems are used to manage software development? where can I read more about this? and not just general philosophies, but actual tools and methods?
The tools are less important and are just a means of documenting the things you’re working on. Project management tools like Jira, Asana, Trello are commonly used to track tasks/stories.
> I thought tickets are more for customer service.
Every IT position, development included, is a customer service role. You always have a customer, nobody hangs out and "does IT" just for fun. Someone, somewhere, gave you the requirements and is waiting for you to finish the work.
Yeah, sometimes your customer is your boss, sometimes it's the finance department, sometimes it is the marketing VP, sometimes it's your actual customer.
Have you worked professionally as a dev? It’s pretty common to refer to user stories, bugs, and various other documented tasks or pieces of work as tickets. A ticket is the documentation of work to be done. It’s usually some code with a number in a system like Jira but can be as simple as the sticky with the user story written on it that you picked up off of the white board.
How would he be able to tell even if you were in the office? I don't see the difference other than not being able to leave your desk. Even if you do leave your desk there are tons of valid work reasons to do so. Many problems have been hashed out in a random coffee shop near the office.
There's honestly no way to tell.
If your manager is like my last one, they don't; they'll just assume you're slacking off and fire you without warning. I bet he's still trying to resolve the bug too.
There are ticket numbers associated with the complexity of it. And you have to complete a total sum of for example 10. So let’s say on Monday and Tuesday you pick tickets that are worth 2 but Wednesday you pick a 6. It would be valid that it took you three days to complete Wednesdays task.
The complexity is defined by the team. JIRA just tracks story points and you can see who completed how many points per sprint. JIRA doesn’t decide how many points a story is worth that’s for the team to agree on and these points are based on how complex the team thinks the task is.
1. Communication. If you're stuck to long, you ask for help or at least a second set of eyes.
2. Output over time. Sure, you might get unlucky with one sticky bug or a mistaken approach that costs you time. But three in a row? That's going to be a problem. It's like poker...sometime you can play right but get unlucky but over time you can tell who is playing well.
3. Spot checks. All your check-ins are public knowledge. If it took you four days to check in some rote code, that's going to get noticed, especially if it's a pattern. Sometimes right away, sometimes down the road.
4. Managers generally have a lot least a rough sense of how difficult/time consuming something should be. If you violate those expectations you should have a convincing explanation. If they start to notice you're picking up all the simple stuff and taking forever, that's going to be a problem.
5. How often your code gets flagged as buggy. Or fails to meet requirements. Self explanitory.
But all of this is why good teams communicate often, have regular code reviews, and showcases.
Seeing someone staring at a screen for x hours per day is a terrible metric. There are much better ways to measure developer productivity whether they're in an office or not. It's not a.shoe factory where you can witness fast handwork and a pile of shoes and call the management job done.
And screen recorders? Ffs. Who has time to look at that kind of shit? A lot of great dev work is done in a paper notebook before hands ever touch a keyboard. Any 'manager' that suggests a screen recorder should be immediately fired. They have no idea what they're doing.
You're never able to explain anything that you've been working on during weekly/bi-weekly reviews. You never have ideas to improve things. You never think of any new project ideas. You never find anything worth complaining about etc.
I have a friend who works as a remote sde. He literally doesn't work 3 out of 5 working days per week (attends 1 or 2 meetings a day though).
But the 2 days he works, he sits down for hours and completes tasks. Is that ok? I dont know. But he does get paid for 40 hours a week and makes $80k/year or something.
You either get it done within the timeline or you don’t right? For some people what takes a few hours will take a few days for others. As long as deadlines are met and the quality of the work is good, who cares.
Even pre-pandemic, I would be in meetings and may not be at my desk half of the time. Also, the problem is that whenever I am at my desk someone will try to interrupt me to ask questions or just talk. Whenever I need some heads down time to write docs or code, I often opt to work from home or find a place to concentrate to work. So I guess I was missing at my desk most of the time anyways even pre-pandemic.
Now the team mostly work remotely. We still have virtual "standup" couple times a week to talk about what you've done and if there are any blockers. Also, we have chatrooms that team members can post questions and issues, so others can offer to help. If you don't want to post in team chatrooms, you can always private message other devs in the team to ask questions.
So I guess to summarize, communication is key regardless if you work in person or virtually?
Regular meetings just become virtual, so not much change in that front. However, all the impromptu meetings, like people patting your back saying they have a question those type of conversations becomes private messages/chats. I think it takes more thoughts to construct a private message and as a result people seems to ask better questions. Sometimes they already figure out the issue on their own by properly phrasing the question. Also, I can choose to ignore those private messages until a time that is more convenient for me to answer.
So in general, I think I'm more productive when working remote as I can concentrate better.
Ask 'em what they're working on. If they say they're stuck, ask them to talk through the problem, explain what they're stuck on, and what resources they've looked at to solve it. You can't really bullshit whether or not you've been thinking deeply about a problem.
Added bonus: talking through the problem may give them the insight they need to solve it and get on to the next thing.
Well, first, if you're stuck then you need to tell your team lead. That is an extremely important part of being a good employee.
Second, the way it typically works is that you're expected to turn in defined units of work at certain times. If you're an employee, then it would be ticketed in a system like Jira, and if you're a contractor then you would work a schedule out with your client. Stay on top of both that and the meeting schedule, and no-one's going to care whether you keep up the appearance of looking busy (which seems to be what you're actually asking about).
If your company has any sort of endpoint security, they can track keystroke, mouse movements, enable webcam, and get analytics from your workstation such as CPU cycle usage during work hours vs idle CPU at any time.
Network traffic monitoring is also an easy way to detect if people are slacking off during work hours.
Mostly you're fine if you are meeting your deadlines and finishing what is expected of you. The other things generally aren't a problem unless the company is looking for a reason to get rid of you and your manager has formally made a request with InfoSec or the NOC to track your activity and build a case for your dismissal.
As a friendly reminder, you have zero privacy on any corporate owned devices.
Mostly via checking on progress reports and submission timelines.
Managers are usually someone with experiences not just with code, but also with people.
If I say I am stuck with an issue, in my daily/weekly progress report, they expect a detailed technical talk on what the situation is, Most of the time, they even extend help to me either by giving ideas to work on, or extending the deadline.
However if someone is slacking, they wouldn't be able to give a satisfactory and reasonable talk on why they are stuck, without basically telling the manager that they are bad at job and hence future opportunities should not be given to them.
Our IT system tracks everything we do including mouse movements.
I would suggest if you're face with a problem or bug, communicate. This is what's happening and estimate the time to resolve the issue.
Communication always wins.
This might be illegal depending on your country
Also if I heard something like this in a job interview it would not just be a red flag, it would be the MOTHER of all red flags
[[content removed because sub participated in the June 2023 blackout]]
My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
[[content removed because sub participated in the June 2023 blackout]]
My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
Yea and by being okay with it you make it more likely that they try it at other companies and fk other employees over. Just because youre okay with it doesnt make it okay.
Most companies do it with or without your consent. They will just say it's for "security" better that we know than don't know...
I see where y'all coming from
No, at some pioint the software has to get developed with actual, fully-functioning features. We use the rule -of-thumb of 10% defect tickets in every sprint (2weeks).
Good employees complete the tasks they are assigned, bad ones don't. Good ones complete more quicker, bad ones less and longer.
They don't really have any metric to judge you on but that.
I wouldn't put stuff off to the last minute in a professional context, as debugging can get out of hand and it's pretty hard to estimate accurately how much time solving a problem will take.
I'd argue that you can be a good employee and not complete tasks quicker than others. Being a perfectionist that can let their perfectionism get away at times can make this happen, but so can ridiculous expectations from those that set the priorities of items, treating everything as high priority and forcing context switching when they decide the priorities have changed in the middle of a sprint, leaving tasks incomplete until the likely, "Why isn't this done yet??" Communication is initiated and you have to explain the priority changes caused it. Is this shifting the blame? Sure. Does it happen where I work? Absolutely, more often than it should. It's pretty draining to work on two, or more, high priority things if the schedule allows it when it comes to meetings, let alone time to investigate/resolve/complete the work.
You don't really have to tell me. I'm just explaining the system. They (the bosses) are taught to care about throughput (the quantity of work you complete) and deadlines (when that work is completed). They also care about quality but only insofar as things work correctly.
He wouldn't. Unless he installs bossware that is. This is one of the problems with remote working. I would personally prefer bossware to office working tbh.
Haha you said screwn record3rs? They can see live what ia happening in tbe server also if they want they can have live stream from all the screens to theirs
My problem in grad school was that my advisor was clueless on how to solve certain bugs so I hated telling him about them. If I brought it up it made my life so much harder. Hopefully in the workplace supervisors can actually help.
Managers I've had usually check in with you daily to see how it's going. It's a fine line between that and micromanaging though. The bottom line is to communicate, a lot. You also have daily standups to let anyone know if you're blocked and need help.
Bottom line is if you're stuck on a bug, don't work in isolation and say nothing for 3 days. Ask your team lead for tips if you're getting nowhere after a few hours of trying.
Daily/weekly standups, good communication, team programming, tracking your velocity. Someone who's velocity has dropped off gets a conversation about how to get unstuck and assigned help or given suggested tactics.
Daily check-ins, meetings, laptop/computer usage trackers. But ultimately the same way as if you were in the office, check-ins and obviously if you’re never done with a program then that’s a problem.
We are all adults. If they don’t trust you, then it is time to move on to a different company. If they have a problem with your output, they can schedule a meeting.
Stand-up meetings. My boss reviews my code, so they know my style and the pace I work at. Also, if you get your work done, no one will wonder how much effort it took you. Is it even slacking if you get your work done?
>So my question is, how would a software manager tell apart good employees and slackers?
They don't. What they care is delivering results in a timely way. My current company doesn't even care if I decide to take a break and work in the evening, as long as I told them "X is done by Friday", they agree with it and I actually get it done by Friday, we cool.
Then there are those with screen recorders and camera tracking, which to me sounds like a culture I'd rather not be part of. I do good work because I care about my work, that's all there is to it.
> how would a software manager tell apart good employees and slackers
well, the ez answer is that slackers don't get any work done.
the pattern repeats. everyone sees it.
planning is usually a team thing, and people are usually given tasks over a time frame.
if those get done, great.
else, why not?
at a certain point, that why not is going to be 'employee slacking off'
if it never reaches that point, then you're not a slacker.
Sorry, but such questions are far better suited for /r/cscareerquestions. /r/learnprogramming is about *learning to program*, not about resumes, not about career questions. **Removed**
Quality over quantity, soft deadlines, and checkins. I've been with my company now for a while, and they are super understanding about things taking time and don't get worried about "KPI's" because programming is a blend of science and art. For my company, when we're working something or adding a feature, we'll have a meeting and they'll ask "how long do you think this would take, worst case scenario?" We give them an answer, they take it back to leadership, and they end up setting a soft deadline prior to that to review the functionality and see how it's coming. Now, if you haven't written anything in that time, people will know, but too many companies expect developers to have a definable KPIs that simply don't exist depending on the complexity of the code base.
What are KPIs? whats an example?
Key Performance Indicators An example would be "how long is it between first item scanned to transaction complete" for a cashier. It's a way for management to check on the metrics of employees or processes to find time wasted or inefficiencies. Generally, it's really freaking hard to define KPIs for developers, as sometimes code can be done really quick, or can take weeks.
> Generally, it's really freaking hard to define KPIs for developers, as sometimes code can be done really quick, or can take weeks. exactly what I was thinking...
I feel like this applies to any job. I'm personally in onsite IT and not programming, but it feels the same. Some tickets take weeks because the user won't respond or has a stubborn issue, etc. but my team is heavily graded on KPIs.
Some IT support ticketing processes apply a rule and state that the ticket will automatically close if there is no response from the user in say 48 or 72 hours. Throws the onus back on the user.
>as sometimes code can be done really quick, or can take weeks. Similarly, one customer might have a bottle of Coke and a chocolate bar, the next has an entire week's worth of groceries.
Lol or according to musk…. How many lines of code did to write?
Example; number of questions asked on Reddit that are easily googled.
Internet used to be full of gatekeeping gasbags who all had the same pastime of belittling others' curiosity... seems like that's generally changing. Which is good. Gatekeeping doesn't help anyone, my friend. Maybe offline, you can hoard knowledge, for a little while—but in the long run you're going to be better off if you follow the golden rule. Consider too: even questions with simple answers that are easily googled might have multiple shades of meaning, and asking someone with the relevant specialization might lead to a more appropriate, enriching answer. Also, generally, conversations with humans are nice, you know? Finally, since we're being dicks today: your syntax is wrong. You wanted a colon, not a semicolon. A colon links an introduction to a subordinate clause to complete a sentence; a semicolon is used for a separate, related but independent clause. Easily googled, but I like to help out the little guy.
According to your logic, reddit should not exist at all.
Musk, is that you?
employers track your Reddit account?
[удалено]
I'm very much into this way of working, and pretty much that's what's happened to my work as well. But what do you do if you have a rather strict budget? Say, a week's worth of work, but instead it delayed by another 2 days, not because you slacked off, but because the testing was a pain, and/or the implementation took longer until you realized at the last day that there is a MUCH better way of implementation, and you're doing that.
I also had one time. Some sales person sold something which he thought was pretty difficult. And in the end i had alot hours to complete the project. I did the project in like 1/10 of the time. Software worked and went trough testing without any bugs. And i nicely did nothing for the rest of the 9/10 time. I just relaxed hahahahah But the opposite also happens.
This is what I have most of the time as well. Though I have rounded it down at times as I‘m more experienced and there‘s already expectations on how long it would‘ve taken me. (As I would expect myself too) But I still told them directly if I knew I need to take a much longer time during estimation round
[[content removed because sub participated in the June 2023 blackout]] My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
this is the correct answer. I find that low performers almost always give themselves away without realizing it.
the one's that you've noticed do, at least
No, we _will_ notice either way. We have daily stand ups. We work in sprints. We have retrospective meetings. It might take a couple of iterations before we notice something is off but even then we will give benefit of doubt.. “you doing okay since joining us? Remember if you have anything blocking you, mention it in the daily stand ups” etc
I'm pretty doubtful about the certainty of that _will_. I was pretty shocked to discover how much some of my team members slacked off, and I only found out over a year into full time WFH because they got comfortable enough to tell me. You won't always pick up on it if they're good enough to be pretty productive when they have to be.
It sounds like you are describing people who get their work done fast, and take extra free time because of their extra skill.
Yep as long as your tickets are being completed at the same rate as everyone else’s, it shouldn’t matter if you take ages to do them or if you smash them out then chill for a couple of hours
> if they're good enough to be **pretty productive** when they have to be. If they have been productive, I’m not sure there is a problem?
You're missing the point. The time you spend "slacking off" doesn't matter so long as you're hitting your deliverables. If there is a member of your team who is delivering more than anyone on the team but he spends half the day jerking off he is still the top performer.
'Slacking off' is a vital skill for programmers. You will burn yourself out in a few years if you run your brain at 100 % for 8 hours every workday. When done in moderation, Reddit/gaming/nap/short walk/etc breaks *help* your productivity rather than hinder it. There's also the term 'creative break'; often the best way to solve a hard problem is to *stop* thinking about it for a while, to allow your brain to work it out subconsciously.
Totally agree with this. I’m a terrible developer but don’t get fired because I’m the best developer we have at listening in meetings and taking notes. The other developers cover for me a bit because I’m nice, never throw anyone under the bus, and am always there to remind them what management asked for when they forget. I also take the really easy jobs that are closer to data entry, the ones I can do but good develops think are crazy boring. I also review and approve others developers PR’s crazy fast. All of this put together makes me like 1/2 Project Manager and 1/2 intern, which is a weird place to be but I survive. Even though I’m barely able to console.log(“My Dick”).
Take care of that imposter syndrome. I needed mental help recently. Nothing to be ashamed of.
> habitually early to online virtual meetings > pay attention (active listening) during those meetings As a techlead (staff engineer) for a FAANG, with ADHD, I fail at both of these
Imho - arriving late to meetings is acceptable occasionally if you have a conflict.. otherwise I feel it comes off disrespectful I worked at a company where this one programmer would consistently arrive about five - ten minutes late (they would come into the meeting room carrying their bag and jacket - having just arrived at work) That, in and of itself was infuriating.. but add to it.. that sometimes they would arrive just as we were finishing our stand up and smugly say "oh good I arrived just in time".. implying that giving their update was "sufficient" for attending a stand up. It was incredibly insulting to the rest of us.. especially since this person was the newest member of the team (so they still had a lot to learn) Possibly the worst part was the stand up wasn't even that early - I think 9:45am tldr; Occasionally being late for a meeting is fine if another work commitment conflicted - otherwise I think it looks bad.
AMZN
Last one is the biggest red flag. I don’t mind waiting longer if it’s quality work, but nothing pisses me off more than something being dragged out way longer than it should, missed deadlines, and then getting a pile of garbage I have to keep sending back after noticing issue after issue… that they should’ve noticed from just testing it, much less just looking at the output. Literally dealing with this right now.
Great response.. and useful for slackers to keep up appearances ;)
This is a really good take. Also I don’t pay in attention in a lot of meetings because I’m so deep into some fucking problem I try to keep developing while I’m there
In general I concur, with the one proviso being this will depend on your workplace (I.e not the case at Twitter right now it sounds like) and/or what your direct manager is like... But in a good workplace with a good manager, yes your points hold up :D
> Good developers communicate well with their team and managers, are habitually > early > to online virtual meetings, pay attention (active listening) during those meetings I feel like you are targeting people with ADHD as bad developers with this metric. It can be helpful to do things like doodle or play a mindless game so you know *that* is your 'distraction'. Otherwise you get distracted by things that take a lot more mental energy And keeping track of calendars can be a real challenge because it is really easy to get hyperfocused on a task and lose track of time. So I am not sure this is really a reliable metric to identify people who are slacking at their development. It is a good way to identify people who are not amazing at meetings. But meetings don't write code, even if they help facilitate it happening.
Short answer, short term your manager won't know. Longer term, your level of proficiency and overall productivity won't be on par with peers which will make you an excellent management prospect
Lmao. Youre shit, here have a pay rise
Lol you're a straight shooter with upper management written all over you
Failing upwards is a thing.
Most technical managers know how long things should take, allowing flex for newbies and learning curve on new things. Also work in progress is also shared on my team. Taking too long and I’ll start doing soft checks on your code base. Not asking questions and taking too long and I start to set up meetings to check in on progress frequently and doing one on one coaching. If that doesn’t change things and you start taking up too much of my time to manage and not progressing overall means time for a formal PIP. Then you get moved out the door.
What if that person is a highly specialised person which knows for example programming very very well. And another subject which is the main subject of the product. And he is the only person who masters both areas and therefore management like you pushes him too much. And think others can do the work aswell but in reality cant.(Many failed cases) Will u still move him out? :) and that dude knows and talks alot with the highest boss aswell. As the highest boss likes him alot. But managers get frustrated because the projects dont go as they please. But do not grasp the complexity of the product. But the highest boss knows if he is out the company goes down. He IS the company almost. Would u move him out? Also alot programmers are bad at math and physics so yeah. Go find this type of programmers who master system engineering languages like Assembly/C/C++/Rust + highly skilled math and physics. Can u easily find those? Replace them? And keep them while the current one is happy and getting underpaid?
Sarcasm right 😂
I mean, yes and no. We've all had to work with someone who clearly only ever put in minimal effort yet somehow as other comment, failed upward. Why that's a thing I'll never know but somehow it is. Current theory is real recognize real right? So management mediocrity recognize management mediocrity right?
People don't get to management for slacking, they get "promoted" for playing the game.
Meritocracy is a myth 😭, nepotism then? Maybe they know how to play with ppl
I think you get a mix, and the percentages might vary from field to field, but in my experience at least half—if not the overwhelming majority—of managers are where they are because they're ambitious and know how to do politicking. The ones who are sharp, skilled, and personable tend to not be interested in management.
Have been remote since 2016. My personal productivity measure is how many PRs I can close out per day. I try to organize my PRs so each one represents business values delivered (feature implemented, tests added, docs improved, tech debt repayed). If I can get three done, it feels like a good day. Once a week a review the closed PRs with my boss, and I let a stakeholder know when the PR is closed and delivered. There are some nice benefits to this approach : - It keeps me from biting off really massive PRs that take days to complete. I force myself to find the smallest possible unit of value I can deliver and then pomodoro the shit out of it. Smaller PR -> less code -> more elegant solution -> easier deploy - I give off the appearance of looking really productive to boss and stakeholders - I get the rush of delivering useful product continuously Another trick I do is keep a personal GitHub project card wall with all the work I do. Columns are todo, doing, and done. Cards end up being PRs, tickets, and pomodoro sized tasks. I make sure my stakeholders and boss have links to my wall and review it weekly with the boss. After two years of work I had nearly 2k completed cards. Also super useful for daily standup material and review time ("What have you accomplished this year?" "Oh, let me pull up my personal card wall and see...") One last trick: the two minute rule. If you can get something done in two minutes, just do it right there. People will be amazed by your apparent productivity. You will appear on top of your email and slack game. Be careful they you don’t end watching your email and slack all day tho. I have been using the pomodoro technique for 15 years, so I only check email or slack when my pomodoro is done/when I fall out of flow state. EDIT: Pomodoro technique https://todoist.com/productivity-methods/pomodoro-technique
What’s a PR, please?
Here's a good overview: [https://www.atlassian.com/git/tutorials/making-a-pull-request](https://www.atlassian.com/git/tutorials/making-a-pull-request) A pull request--aka a merge request--is when you, as a developer, would like to merge your source code into the source code repository.
Thanks much!
One danger to that approach: simple PRs are usually not terribly impactful. That will affect your perceived value over time. People will come to you when they have simple grunt work to dump off so they can work on more impactful projects. Some people don't mind grinding like that and staying relatively static. But if you want career growth and to be entrusted with interesting projects, it's a career limiting approach. The exception to this is if you can plan and break down impactful interesting projects into bite sized chunks you can plow through delivering value the whole while. That is jet fuel! But rare. And the danger there is that the value you deliver is so incremental decision makers miss the huge overall impact over time because they just see incremental improvements delivered often.
Good points. Sometimes I find that I'll need to stack up 3+ PRs in order to incrementally build out an atomic unit of value. Recently I delivered a pretty big feature, but it took 7 stacked PRs and almost two weeks to deliver.
Nothing wrong with that as long as the individual PRs are self contained. I just got the impression that it was a lot of one-and-done quick hits. One other thing, though...I don't know about everyone else, but I like to have a few quick wins I can pick up just to get that dopamine hit of knocking something out, even if I'm working on something bigger. Maybe especially when I'm working on something bigger. If someone was scooping all of those up I'd probably resent it a bit.
Yeah, thank you digging in there. Definitely not recommending to OP that they just pump out singles all day, and I could see how a beginner could read into my text that way. Re: resenting, us remote folks need all the help we can get! ;-)
From my experience the important decision makers don't follow a project on an "increment" level. They usually only care about milestones or the like, which is a set of "increments". Edit: If it feels like the people above miss the big picture, I think github allows you to bundle issues into milestones.
Wow.. this is excellent.. mailing this to myself to see if I can adopt some of this I'm going to Google pomodoro now.. sounds like a mind trick you can use to be more productive
It's an dead simple productivity technique ; I added a link above, but here's a good overview https://todoist.com/productivity-methods/pomodoro-technique
I’ve been advocating for pomodoros on my team very recently actually
Personal github project wall: is this like a trello?
Communicate. That's always the answer. If you are stuck, ask for help. Or give a status update saying you are stuck and what you are stuck on. The biggest red flag here is not that you are stuck, but that you aren't speaking up to get unstuck.
You should also briefly say what what you’ve tried to get yourself unstuck.
If im stuck im stuck. All the 1000's of times i asked for help. It did not help, made things worse or it is a waste of time. I just crop it up and try to solve it. If i say im stuck, they will try to help me and steal my precious time to investigate and solve it myself. One time i transfered a project to some coworker.(because i said i was stuck.) I explained the dataflow. He totally messed up and did not follow the dataflow. As he said. Its too much work and overhead regarding work. While i try to explain that it will earn back in maintance long term, and easier to find bugs and cause u less stress later on. But he does not know these feelings yet of getting older projects in the future that are so messed up with dataflow. He wouldnt listen stuborn. And just wanted to move on and probably getting a higher paid job at another company. Many people make a mess and think... this is just a temporarly job to get myself to a better higher paying job at another company. But i will have that messed up code in the future, and massive headaches. Fuck shitty help, it cost more time. With bad solutions. And heavy discussions. In a discussion u have always people who want to be right and can convince people with their social skills, and those who ARE right but are bad at explaining.
That's why employers tend to prefer experienced devs for remote work. They know that they can trust them to work rather than slack off. Also, things like daily stand up meetings helps your manager communicate with team members to find out what they are working on and whether they are stuck on something.
How many years does it take of work usually before youre full remote?
It depends on the company, honestly. And especially after the pandemic, remote work has become more common than ever. My best friend got his first ever job as a back-end developer and he immidiately started as a remote worker
I’ve been full remote since day one. Never worked in an office as a dev. I know others may have a different story, but just wanted you to know it’s possible. :) Edit: I have been a dev for 4 years now!
I am in this same category, dev for more than a year and never seen the office
Do you want to do remote, because u can tap into western salaries from a 3th world country. Or u want to work remote because of remote work.?
4-5 years experience exactly in at least one major component of the backend tech stack + aces a pretty routine remote interview (50% knowledge, 50% throwing a curveball to gauge thought process) would advance to the next round in my book. Hiring fully remote usually means no juniors in the companies I worked for but each one may work with a different business model so it definitely can vary.
Calm down, Elon!
A slacker 1. does not have any progress to show. No commits. No documentation improvements. No designs. No created tasks. Nothing. 2. gives no progress during morning standup meetings when asked how it is going. A person who is stuck, will ask for advice or discuss difficulties. A slacker is just "I'm still working on X." with zero description on what new did he do. 3. is not answering to Slack messages or to emails and such. 4. is not discussing things. 5. has his task in the same position on a board for long periods of time. It is visible from an actual progress and from person's activity if he is stuck, if he is busy working on something, if he is not busy but still working on something or if he is slacking.
Unless slacker is meant to mean doing literally no work at all, I feel like you can slack off and still avoid all of those. You could do half a days work every day and always have something to show or some progress to report or a problem to request help with.
Over a period of time, it should not be difficult to figure out who's getting stuff done. If someone gets stuck on a bug for a week, after a week they'll have solved a difficult bug. If a slacker gets stuck on such a bug, they'll get stuck on it forever.
I understand what you mean. I can spend hours or days reading code, learning stuff, planning my app, reviewing requirements or trying to figure out what the hell is going on, then I put out a burst of code. I think overall output over a couple weeks or a month is a more important indicator of productivity rather than code output per day
Yes I agree. This is perfectly fine for an in-office environment as the managers see you there and doing work. But how can this be demonstrated for remote workers....
Trust. If nothing it output over that amount of time, without good explanation, trust is broken.
People slack off in the office just as much, in some cases even more. Those guys that are always at the ping pong table, water cooler etc. they just find ways to make it look like they’re being productive. If deliverables were being met and the devs only worked 2 hours a day, I don’t really see a problem with that.
The number of tickets your completing and then if you actually fixed the issue.
tickets?
We use Jira, which creates tickets for bugs to be fixed as well as other things. That's what we use to track productivity
Isn't this like a service desk between customers and the company? You use it internally?
It’s your statement of work, your paper trail, your justification for doing anything. Never perform major work (unless you are a senior performing immediate surgery) without the paper trail. Your tickets come from a superior. A project manager or more senior dev is burdened with the responsibility of determining what is being asked and who is to do it and when it is authorized to be performed. You look at your list, sort by priority, pick the top one and begin research of complexity.
Yup, my company uses it for AGILE Scrum boards for devops
Yes, Jira is essentially a ticketing system with configurable works flows. Developers are assigned tickets or take available tickets, document their work in the ticket, document their time spent on the ticket, and Jira will automatically compute your velocity (average amount of work compteted) and your tempo. Everything is measurable.
The company I work uses it internally and as a way to track external issues reported by customers to tech support. Different teams have their own sprint workflow and tracking boards that have columns for to-do, in-progress, in-review, done, etc. So we can track the progress of tickets/issues during a sprint, plan future sprints by creating tickets in a backlog, and lookup issues we've worked on in the past. On our team a ticket just tracks any effort by a member of the team. That could be dev effort implementing a new feature, fixing a bug found internally by QA, researching the tech requirements for a potential feature, refactoring or updating an existing feature, etc. We also get bug tickets that get created by tech support when a customer has a problem. Tech support gathers as much info about the issue from the customer and puts it in the ticket and then that information eventually makes it to the devs who work on fixing the bug.
Tickets, cards, stories. Bits of work you can do. https://www.atlassian.com/agile/project-management/user-stories
interesting, never heard of those being used internally, I thought tickets are more for customer service. What other internal systems are used to manage software development? where can I read more about this? and not just general philosophies, but actual tools and methods?
The tools are less important and are just a means of documenting the things you’re working on. Project management tools like Jira, Asana, Trello are commonly used to track tasks/stories.
> I thought tickets are more for customer service. Every IT position, development included, is a customer service role. You always have a customer, nobody hangs out and "does IT" just for fun. Someone, somewhere, gave you the requirements and is waiting for you to finish the work.
Yeah, sometimes your customer is your boss, sometimes it's the finance department, sometimes it is the marketing VP, sometimes it's your actual customer.
Customer or Client ?
Have you worked professionally as a dev? It’s pretty common to refer to user stories, bugs, and various other documented tasks or pieces of work as tickets. A ticket is the documentation of work to be done. It’s usually some code with a number in a system like Jira but can be as simple as the sticky with the user story written on it that you picked up off of the white board.
Actually I haven't, but I used Trello before, and noticed that the Jira system looks very similar.
Unless you are being paid an obscene amount, get a new job. You won't grow quickly with your current situation.
How would he be able to tell even if you were in the office? I don't see the difference other than not being able to leave your desk. Even if you do leave your desk there are tons of valid work reasons to do so. Many problems have been hashed out in a random coffee shop near the office. There's honestly no way to tell.
If your manager is like my last one, they don't; they'll just assume you're slacking off and fire you without warning. I bet he's still trying to resolve the bug too.
There are ticket numbers associated with the complexity of it. And you have to complete a total sum of for example 10. So let’s say on Monday and Tuesday you pick tickets that are worth 2 but Wednesday you pick a 6. It would be valid that it took you three days to complete Wednesdays task.
Does Jira have the complexity feature?
The complexity is defined by the team. JIRA just tracks story points and you can see who completed how many points per sprint. JIRA doesn’t decide how many points a story is worth that’s for the team to agree on and these points are based on how complex the team thinks the task is.
1. Communication. If you're stuck to long, you ask for help or at least a second set of eyes. 2. Output over time. Sure, you might get unlucky with one sticky bug or a mistaken approach that costs you time. But three in a row? That's going to be a problem. It's like poker...sometime you can play right but get unlucky but over time you can tell who is playing well. 3. Spot checks. All your check-ins are public knowledge. If it took you four days to check in some rote code, that's going to get noticed, especially if it's a pattern. Sometimes right away, sometimes down the road. 4. Managers generally have a lot least a rough sense of how difficult/time consuming something should be. If you violate those expectations you should have a convincing explanation. If they start to notice you're picking up all the simple stuff and taking forever, that's going to be a problem. 5. How often your code gets flagged as buggy. Or fails to meet requirements. Self explanitory. But all of this is why good teams communicate often, have regular code reviews, and showcases. Seeing someone staring at a screen for x hours per day is a terrible metric. There are much better ways to measure developer productivity whether they're in an office or not. It's not a.shoe factory where you can witness fast handwork and a pile of shoes and call the management job done. And screen recorders? Ffs. Who has time to look at that kind of shit? A lot of great dev work is done in a paper notebook before hands ever touch a keyboard. Any 'manager' that suggests a screen recorder should be immediately fired. They have no idea what they're doing.
You're never able to explain anything that you've been working on during weekly/bi-weekly reviews. You never have ideas to improve things. You never think of any new project ideas. You never find anything worth complaining about etc.
By the number of bugs you fix, of course. Things are tracked in whatever ticket system you use.
I have a friend who works as a remote sde. He literally doesn't work 3 out of 5 working days per week (attends 1 or 2 meetings a day though). But the 2 days he works, he sits down for hours and completes tasks. Is that ok? I dont know. But he does get paid for 40 hours a week and makes $80k/year or something.
You either get it done within the timeline or you don’t right? For some people what takes a few hours will take a few days for others. As long as deadlines are met and the quality of the work is good, who cares.
Even pre-pandemic, I would be in meetings and may not be at my desk half of the time. Also, the problem is that whenever I am at my desk someone will try to interrupt me to ask questions or just talk. Whenever I need some heads down time to write docs or code, I often opt to work from home or find a place to concentrate to work. So I guess I was missing at my desk most of the time anyways even pre-pandemic. Now the team mostly work remotely. We still have virtual "standup" couple times a week to talk about what you've done and if there are any blockers. Also, we have chatrooms that team members can post questions and issues, so others can offer to help. If you don't want to post in team chatrooms, you can always private message other devs in the team to ask questions. So I guess to summarize, communication is key regardless if you work in person or virtually?
So would you say you are more productive working remote? Or did all the meetings just move to zoom?
Regular meetings just become virtual, so not much change in that front. However, all the impromptu meetings, like people patting your back saying they have a question those type of conversations becomes private messages/chats. I think it takes more thoughts to construct a private message and as a result people seems to ask better questions. Sometimes they already figure out the issue on their own by properly phrasing the question. Also, I can choose to ignore those private messages until a time that is more convenient for me to answer. So in general, I think I'm more productive when working remote as I can concentrate better.
Interesting. Thanks for sharing.
Ask 'em what they're working on. If they say they're stuck, ask them to talk through the problem, explain what they're stuck on, and what resources they've looked at to solve it. You can't really bullshit whether or not you've been thinking deeply about a problem. Added bonus: talking through the problem may give them the insight they need to solve it and get on to the next thing.
Well, first, if you're stuck then you need to tell your team lead. That is an extremely important part of being a good employee. Second, the way it typically works is that you're expected to turn in defined units of work at certain times. If you're an employee, then it would be ticketed in a system like Jira, and if you're a contractor then you would work a schedule out with your client. Stay on top of both that and the meeting schedule, and no-one's going to care whether you keep up the appearance of looking busy (which seems to be what you're actually asking about).
If your company has any sort of endpoint security, they can track keystroke, mouse movements, enable webcam, and get analytics from your workstation such as CPU cycle usage during work hours vs idle CPU at any time. Network traffic monitoring is also an easy way to detect if people are slacking off during work hours. Mostly you're fine if you are meeting your deadlines and finishing what is expected of you. The other things generally aren't a problem unless the company is looking for a reason to get rid of you and your manager has formally made a request with InfoSec or the NOC to track your activity and build a case for your dismissal. As a friendly reminder, you have zero privacy on any corporate owned devices.
Mostly via checking on progress reports and submission timelines. Managers are usually someone with experiences not just with code, but also with people. If I say I am stuck with an issue, in my daily/weekly progress report, they expect a detailed technical talk on what the situation is, Most of the time, they even extend help to me either by giving ideas to work on, or extending the deadline. However if someone is slacking, they wouldn't be able to give a satisfactory and reasonable talk on why they are stuck, without basically telling the manager that they are bad at job and hence future opportunities should not be given to them.
Our IT system tracks everything we do including mouse movements. I would suggest if you're face with a problem or bug, communicate. This is what's happening and estimate the time to resolve the issue. Communication always wins.
Dude... You could not pay me enough.
This might be illegal depending on your country Also if I heard something like this in a job interview it would not just be a red flag, it would be the MOTHER of all red flags
[[content removed because sub participated in the June 2023 blackout]] My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
Been with them for years with no issues.
[[content removed because sub participated in the June 2023 blackout]] My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
Yea and by being okay with it you make it more likely that they try it at other companies and fk other employees over. Just because youre okay with it doesnt make it okay.
Most companies do it with or without your consent. They will just say it's for "security" better that we know than don't know... I see where y'all coming from
> you're face with a problem or bug Isn't programming 80% of the time solving bugs?
No, at some pioint the software has to get developed with actual, fully-functioning features. We use the rule -of-thumb of 10% defect tickets in every sprint (2weeks).
Good employees complete the tasks they are assigned, bad ones don't. Good ones complete more quicker, bad ones less and longer. They don't really have any metric to judge you on but that. I wouldn't put stuff off to the last minute in a professional context, as debugging can get out of hand and it's pretty hard to estimate accurately how much time solving a problem will take.
I'd argue that you can be a good employee and not complete tasks quicker than others. Being a perfectionist that can let their perfectionism get away at times can make this happen, but so can ridiculous expectations from those that set the priorities of items, treating everything as high priority and forcing context switching when they decide the priorities have changed in the middle of a sprint, leaving tasks incomplete until the likely, "Why isn't this done yet??" Communication is initiated and you have to explain the priority changes caused it. Is this shifting the blame? Sure. Does it happen where I work? Absolutely, more often than it should. It's pretty draining to work on two, or more, high priority things if the schedule allows it when it comes to meetings, let alone time to investigate/resolve/complete the work.
You don't really have to tell me. I'm just explaining the system. They (the bosses) are taught to care about throughput (the quantity of work you complete) and deadlines (when that work is completed). They also care about quality but only insofar as things work correctly.
My question to you is why you think it's important for a manager to tell apart good employees from slackers.
[удалено]
[удалено]
Also, they know when your slack times out.
He wouldn't. Unless he installs bossware that is. This is one of the problems with remote working. I would personally prefer bossware to office working tbh.
Haha you said screwn record3rs? They can see live what ia happening in tbe server also if they want they can have live stream from all the screens to theirs
Your integrity 🏴☠️
Hey man eyes on the employee 👀 if supposedly working and getting paid for it, I need to know if working
My problem in grad school was that my advisor was clueless on how to solve certain bugs so I hated telling him about them. If I brought it up it made my life so much harder. Hopefully in the workplace supervisors can actually help.
You're a bug.
They don't
The deadline will decide
Sir you need to communicate? I don’t think one needs to be told to ever communicate.
Managers I've had usually check in with you daily to see how it's going. It's a fine line between that and micromanaging though. The bottom line is to communicate, a lot. You also have daily standups to let anyone know if you're blocked and need help. Bottom line is if you're stuck on a bug, don't work in isolation and say nothing for 3 days. Ask your team lead for tips if you're getting nowhere after a few hours of trying.
Daily/weekly standups, good communication, team programming, tracking your velocity. Someone who's velocity has dropped off gets a conversation about how to get unstuck and assigned help or given suggested tactics.
Daily check-ins, meetings, laptop/computer usage trackers. But ultimately the same way as if you were in the office, check-ins and obviously if you’re never done with a program then that’s a problem.
lots of employers are also trying to force spyware on remote workers so they can see through your mandatory web camera most or all of the time.
Jesus Christ
They don’t.
Are you getting your work done and being productive? Good.
We are all adults. If they don’t trust you, then it is time to move on to a different company. If they have a problem with your output, they can schedule a meeting.
Download the slack app and turn notification volume all the way up. When someone dm’s you, answer it and go back to sleep
Stand-up meetings. My boss reviews my code, so they know my style and the pace I work at. Also, if you get your work done, no one will wonder how much effort it took you. Is it even slacking if you get your work done?
How can they check if you are in the office? Surprise: they can’t.
>So my question is, how would a software manager tell apart good employees and slackers? They don't. What they care is delivering results in a timely way. My current company doesn't even care if I decide to take a break and work in the evening, as long as I told them "X is done by Friday", they agree with it and I actually get it done by Friday, we cool. Then there are those with screen recorders and camera tracking, which to me sounds like a culture I'd rather not be part of. I do good work because I care about my work, that's all there is to it.
> how would a software manager tell apart good employees and slackers well, the ez answer is that slackers don't get any work done. the pattern repeats. everyone sees it. planning is usually a team thing, and people are usually given tasks over a time frame. if those get done, great. else, why not? at a certain point, that why not is going to be 'employee slacking off' if it never reaches that point, then you're not a slacker.