81–90 of 200 posts
Open communication is always key. It should feel like a family. The manager/lead needs to be strong, decisive, and protect their people from all the politics.
Learning should always be an opportunity. Engineers should feel safe taking risks and making mistakes.
My current one. I work as the only dev for a small manufacturing company. I work alone, in a big quiet office with nice hardware, a comfortable desk and I get to choose all technical choices and set dev priorities. My boss is ridiculously smart (hard science background) and trusts me to do what I’m good at while he does what he’s good at. I work 9-5 every day. It’s basically programmer heaven.
9-5 absolutely kills me. Is that by choice or because that’s what everyone else does? When programming I can do my best work with big 10-12 hour sprints when the mood strikes and maybe a couple in a row. Then there are days with meetings or days waiting for QA or other feedback where the right thing is literally to just go home for the day at lunch time. My best environment is where I’m treated like an adult with res…
My current one. I work as the only dev for a small manufacturing company. I work alone, in a big quiet office with nice hardware, a comfortable desk and I get to choose all technical choices and set dev priorities. My boss is ridiculously smart (hard science background) and trusts me to do what I’m good at while he does what he’s good at. I work 9-5 every day. It’s basically programmer heaven.
Were you consciously looking for it or did it turn out this way by accident?
The other one was for a larger company in a big open office.
It wasn't even a choice tbh I can't articulate how much I loathe open offices.
Innovation comes from the bottom more frequently than the top, and given time to understand a problem and stew on what is really needed there are rare engineers who can drive the very best work. If the environment stymies that then all is lost, they and others will leave.
My best work has been in the context of supportive, light-touch leadership, high autonomy teams, the ability to really own a problem.
Earlier quoted context omitted.
9-5 absolutely kills me. Is that by choice or because that’s what everyone else does? When programming I can do my best work with big 10-12 hour sprints when the mood strikes and maybe a couple in a row. Then there are days with meetings or days waiting for QA or other feedback where the right thing is literally to just go home for the day at lunch time. My best environment is where I’m treated like an adult with res…
I entirely agree that general standards of productive time are not at all productive with many people. But the problem isn't just the time of day people work, it's the compensation they receive for it. If you're told to build X, you might do it in a day, a week, or a month, many companies or managers wouldn't be able to tell what was appropriate. On the other hand, if you were told that you would receive Y percent of…
As for a sense of ownership, not a problem when you're the only dev.
I own everything that isn't the windows server and desktops.
All the Linux servers, the network, the android terminals the production software, driver terminals etc are all my responsibility.
Earlier quoted context omitted.
I entirely agree that general standards of productive time are not at all productive with many people. But the problem isn't just the time of day people work, it's the compensation they receive for it. If you're told to build X, you might do it in a day, a week, or a month, many companies or managers wouldn't be able to tell what was appropriate. On the other hand, if you were told that you would receive Y percent of…
For me it's the freedom to set my own priorities, tell me what you want and I'll build it. As for a sense of ownership, not a problem when you're the only dev. I own everything that isn't the windows server and desktops. All the Linux servers, the network, the android terminals the production software, driver terminals etc are all my responsibility.
I'm still owed $14k for my work, which I'll probably never see, but I'm proud of the work I did. It gave me something to talk about in interviews and probably made me more money than I'm owed.
My first software engineering job was with a big aerospace company about 20 years ago. Back then, budgets were big and the culture was completely different. Even the lowest peon had a huge cubicle with lots of desk space and privacy. Standups were not a thing and Agile wasn’t on the radar. We had lots of time to do anything we were assigned and never had to do much reporting aside from weekly meetings. We all had a g…
This reminds me also of my most productive days. Funny how enough people create their own middle management jobs, and jobs like "scrum master", that literally seek to destroy developer time.
We can’t really ever hope to make progress with improving productivity or work environments if people contribute to be this reductive.
A “scrum master” role does obviously not “literally seek to destroy developer time” - it’s a patently ludicrous assumption. But if you are in a situation where this is happening - rather, where a “scrum master” role is getting in the way of work - then it does point to something else going wrong in your organisation.
Earlier quoted context omitted.
This reminds me also of my most productive days. Funny how enough people create their own middle management jobs, and jobs like "scrum master", that literally seek to destroy developer time.
If your Scrum Master is destroying developer time, then s/he is "doing it wrong". The main function of the Scrum Master is to shield the developers from all the non-development crap. I've worked with one guy who was so good at it he would play interference and defend us from outside interruptions almost literally (actually blocking people from coming to our desks, making sure we could focus, holding meetings only if…
Of course also that, but you're completely right that that is the exact job of the Scrum Master. To "remove impediments". No matter if the impediment is some process or a manager, it's the Scrum Master's job to remove it.
This actually aligns pretty well with the ideas in Agile Manifesto. And that's why I'm so sad when "scrum master" nowadays mostly seems to mean someone who counts the minutes devs spend on each Jira ticket, and haunt the team when velocity seems to be dropping 10% for the second day in a row.