Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to feel engaged at work: a software engineer's guide

jasont.co

Post reply on HN
Print view View original

51–60 of 183 posts

Re: How to feel engaged at work: a software engineer's guide

#51

Post by dilyevsky »

AlwaysRock wrote: post #22

Eh. These all seem fine. My route? I work less. I have a typical 9-5 but 1-2 days a week I leave a little early and go to do something engaging. Never when I have meetings. Never when I have deadlines. Never when someone is waiting on something from me. But I, and I suspect most engineers, have the capacity to get my work done for a week in less than 40 hours. I used to spend time dicking off on my computer to fill t…

I think Randy Pausch wrote this in his books that once he got family he naturally got more productive during business hours since he just wanted to get all that stuff done and go spend time with his family

Re: How to feel engaged at work: a software engineer's guide

#52

Post by dangerlibrary »

adamsmith143 wrote: post #50
dangerlibrary wrote: post #39

Earlier quoted context omitted.

If managers are spending their days watching the color of the circles next to their team member's names, maybe the managers need more work to do in order to "stay engaged" at work. Of all the bad heuristics for trying to determine whether someone is being productive, this has to be near the bottom of the list. It's the digital equivalent of measuring engineer productivity by looking around the room and seeing who is…

Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This also obviously breeds other bad incentives i.e. the faster you work the more work you get.

It might be time to start looking for a team with a better work culture. There are many of them.

Re: How to feel engaged at work: a software engineer's guide

#53

Post by huehehue »

adamsmith143 wrote: post #37
AlwaysRock wrote: post #22

Eh. These all seem fine. My route? I work less. I have a typical 9-5 but 1-2 days a week I leave a little early and go to do something engaging. Never when I have meetings. Never when I have deadlines. Never when someone is waiting on something from me. But I, and I suspect most engineers, have the capacity to get my work done for a week in less than 40 hours. I used to spend time dicking off on my computer to fill t…

Is your manager just next level laid back? I feel like most places are going to notice and be bothered seeing the yellow circle on your Teams or Slack status consistently for long periods of time.

As a manager - my work habits look pretty similar. If you don't trust your peers or reports, such that you need to monitor the specific hours they're doing asynchronous/solo work, then that's a problem.

The challenge is actually getting people to take advantage of this. I work with folks who default to overworking, so I have to be pretty insistent that they take time for themselves.

Re: How to feel engaged at work: a software engineer's guide

#54

Post by paskozdilar »

adamsmith143 wrote: post #50
dangerlibrary wrote: post #39

Earlier quoted context omitted.

If managers are spending their days watching the color of the circles next to their team member's names, maybe the managers need more work to do in order to "stay engaged" at work. Of all the bad heuristics for trying to determine whether someone is being productive, this has to be near the bottom of the list. It's the digital equivalent of measuring engineer productivity by looking around the room and seeing who is…

Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This also obviously breeds other bad incentives i.e. the faster you work the more work you get.

> from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.

This is true, assuming that:

1. the whole team has approximately equal skill

2. the system is uniform and well-documented

3. the people actually give a shit about the product

If any of these assumptions are not met, then the expectation is naive.

Re: How to feel engaged at work: a software engineer's guide

#55

Post by Tade0 »

> "Oh, I'm just building another CRUD app",

Sometimes that's all there is to it. This is work - fulfillment is optional.

For this reason I try to engage in a measly paid, but interesting project from time to time.

I'm currently in one. I won't be buying that apartment I wanted any time soon, but I can say with confidence that I like my job.

Re: How to feel engaged at work: a software engineer's guide

#56

Post by paskozdilar »

adamsmith143 wrote: post #48
lmarcos wrote: post #42

Earlier quoted context omitted.

Sure, but what would be their argument against it? "Dev X is pushing his features on time, he's a nice college, always learning from him, but... Ah yeah, but he leaves work 1h before everyone else. Please fire him".

Sure but I guess depending on the place I'd think unless you had an explicit agreement about leaving early that there would be pushback. "If you have enough free time to leave early you have enough time to pick up another ticket"

Which leads right back to the "screw around until the clock strikes five" road, which leads to stress, boredom and resentment. Humans are not machines. 100% efficiency is a pointy-haired manager's pipe dream.

Re: How to feel engaged at work: a software engineer's guide

#57

Post by zrail »

jebarker wrote: post #23
VyseofArcadia wrote: post #8

I found this to be an incredibly depressing article. It boiled down to, "think about pleasant things that aren't work." For example, > Pick an activity that you've always wanted to try. Don't have ideas? Try Wikipedia for a good list of hobbies I already have plenty of hobbies, and I'd rather work on any of them than be at work! I've always been very self-motivated. I want to work on what I want to work on. Being for…

I thought point 2 addressed engagement well. If you can get behind the purpose of the whole company, then understanding why your particular cog is important to the machine will help keep you engaged.

My spouse and I do this occasionally, where we pick a business off the street that we're walking by and think about how they make money.

I think it can work for a small business where you can hold the whole thing in your head. It's _much_ harder when you're thinking about a multi-thousand-person enterprise with a dozen product lines.

Re: How to feel engaged at work: a software engineer's guide

#58

Post by leetcrew »

_huayra_ wrote: post #31
yaysyu wrote: post #7

Earlier quoted context omitted.

Bouldering seems to be really popular amongst Software Engineers I know. Taps into many things that Software Engineers typically like. Walls often require problem solving as well as physical ability. Walls are shorter than rock climbing walls (fast iteration cycles/“dev loop”) Lots of different difficulties for a clear sense of progression. Indoors (usually). Can be done solo.

Every one of my coworkers who boulders gets injured (usually lightly) on a regular basis. After climbing (on a rope) for more than a decade, I've never had an injury. Due to the fact you have to ramp up the per-move difficulty much faster on a bouldering problem as the grade increases, the chance per injury on any given move is much higher (e.g. if you chopped a bouldering-sized section out of a 5.12a, it wouldn't be…

injuries come from pushing the limits of your skill and physical fitness. an aggressive climber is much more likely to get injured on a bouldering problem, but you can still mess up your hands crimping on a toprope route you haven't trained for appropriately. you get to choose whether you want to be this person. I never "fall" on bouldering problems. I just climb down if I'm not confident I can make a dyno. I'll never tackle a V8 this way, but who cares?

as for the social aspect, I'd say that depends a lot on your local gym. the toprope area tends to be pretty packed where I go. people are either climbing or belaying; it's not a good place to stand around and chat. in the bouldering area, there's almost always an active conversation going about the newest problems. I find people are very open to a quick chat between problems.

Re: How to feel engaged at work: a software engineer's guide

#59

Post by BeetleB »

AlwaysRock wrote: post #22

Eh. These all seem fine. My route? I work less. I have a typical 9-5 but 1-2 days a week I leave a little early and go to do something engaging. Never when I have meetings. Never when I have deadlines. Never when someone is waiting on something from me. But I, and I suspect most engineers, have the capacity to get my work done for a week in less than 40 hours. I used to spend time dicking off on my computer to fill t…

Pretty much what I was about to say. Instead of finding ways to make something mostly out of your control (i.e. work) interesting, it's better to do less of it and use your free time for interesting projects.

The key, of course, is to get a job that isn't as demanding. Personally, I've found that most of those jobs don't pay more nor have better career growth anyway.

Re: How to feel engaged at work: a software engineer's guide

#60

Post by adamsmith143 »

dangerlibrary wrote: post #52
adamsmith143 wrote: post #50

Earlier quoted context omitted.

Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This also obviously breeds other bad incentives i.e. the faster you work the more work you get.

It might be time to start looking for a team with a better work culture. There are many of them.

I am definitely willing to concede I may be in a bad situation but are there really teams in Agile frameworks with fibonacci pointing where you can pick up a 3-5 point ticket, finish it before the end of a sprint and not work on anything else?
Post reply on HN