[deleted]
The art of interrupting software engineers
211–220 of 255 posts
Re: The art of interrupting software engineers
#212 I got some more ideas on his topic, especially on how much does it cost to hire a programmer:
https://mobilunity.com/blog/how-much-would-it-cost-to-hire-d...
Re: The art of interrupting software engineers
#213There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we…
I'm going to sound really entitled saying this, but I hate morning status meetings because they eventually end up being used as a "this is a reasonable time to expect you to be in the office by" kinda measuring stick lol. It ends up leading to unnecessary stress trying to make the damn 'meeting time'.
Re: The art of interrupting software engineers
#214There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we…
I'm going to sound really entitled saying this, but I hate morning status meetings because they eventually end up being used as a "this is a reasonable time to expect you to be in the office by" kinda measuring stick lol. It ends up leading to unnecessary stress trying to make the damn 'meeting time'.
I know engineers are in demand and we are a high priced commodity but is it unreasonable for a company to expect you to be in office at a certain time? The standup at my current project is at 10:30. And most of us here come around 10.
Re: The art of interrupting software engineers
#215There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we…
I'm going to sound really entitled saying this, but I hate morning status meetings because they eventually end up being used as a "this is a reasonable time to expect you to be in the office by" kinda measuring stick lol. It ends up leading to unnecessary stress trying to make the damn 'meeting time'.
I can completely see it. In the hands of a controlling manager, it can be abused. My manager recognizes that we're usually in the office by 9-9:30 so we walk regularly at 9:30.
Late day meetings are great too if it works better for the team.
In my team's case, we also walk or ride bikes together at lunch. So we can also use that time if necessary, but usually we just keep it casual.
Re: The art of interrupting software engineers
#216I think there's an elephant in the room here, being overlooked: >The engineers would give me highly technical explanation I couldn’t understand. This would frustrate me because I did not add much value and distracted them. I have a rule which avoids this situation happening, ever, and its a controversial one, but bear with me: * NEVER accept management from someone who cannot do your job. This rule, hard and fast, ha…
> Seriously, think about it. How can someone who isn't qualified to do your job, actually manage you?
When put in a leadership position, above all "resist the urge to manage".
I don't want a manager, I want someone who serves the team, insulates them from unnecessary distractions, removes obstacles, etc. Someone that supports a culture of humility, respect and trust while helping to care and feed for each individual's autonomy, mastery and purpose.
I've worked on some great teams and less than 1/2 of the time these leaders could not do my job yet it did not matter (of course it was a bit "easier" when they did) because they understood the above.
Re: The art of interrupting software engineers
#217Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the co…
Agile, XP, insert-other-methadology, is a way to potentially take a developer who is a 2 or 3 and get them working like a 5.
Problem is it also takes the developers who are 8,9 and 10s and turns them into 5s too.
If you have lots of 2s and 3s this is probably fine. If you have more 7s, 8s and 9s it's a problem. For a start the better developers will end up simply leaving as working conditions are too hostile.
Most developers are < 5 / 10 skill wise, so these silly methadologies become stupidly popular.
Re: The art of interrupting software engineers
#218Earlier quoted context omitted.
I'm going to sound really entitled saying this, but I hate morning status meetings because they eventually end up being used as a "this is a reasonable time to expect you to be in the office by" kinda measuring stick lol. It ends up leading to unnecessary stress trying to make the damn 'meeting time'.
I know engineers are in demand and we are a high priced commodity but is it unreasonable for a company to expect you to be in office at a certain time? The standup at my current project is at 10:30. And most of us here come around 10.
It's not unreasonable. My team is usually in by 9, 9:30 at the latest. We take 20 minutes to get coffee and discuss issues, what needs to be done, etc. Then we set about completing tasks.
A startup I worked at in the mid-90's had people working in pairs: a server developer and a client developer. They didn't care what hours you kept as long as you didn't hold up the other person in your pair. I arrived around 9:30am daily. The client guy I was paired with came in around 8:30am. I always stayed later so I'd check in code before I left and leave a message for him about the progress. He tested stuff before I arrived and went over any issues when I got in. Then we'd work together the rest of the day. Other engineers came in at 10:30am, noon, and as late as 1pm. They worked it out with their other halves the same way I did.
I think wise managers work with the team, minding company-imposed limitations, rather than enforce personal preferences.
Re: The art of interrupting software engineers
#219Ah, if you require better visibility into the progress of a sprint why don't you just attend the daily standup where the developers talk about what they have accomplished, what they will be trying to accomplish and if they have any impediments?
There is no need to shoulder tap each and every individual on the development team for a status update. If you are doing that then you don't understand scrum or agile. Maybe a few more years in the industry (myself 20years vs your 3?) and you can write a more feasible blog post.
Re: The art of interrupting software engineers
#220There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…
I love this, makes me want to join team that practices this. What is your book name? I would like to buy it.
The Art of Agile Development. It's published by O'Reilly and quite a bit of it is excerpted on my blog at https://www.jamesshore.com/Agile-Book/ .