31–40 of 200 posts
Working from home, while having a 10 min daily standup voice call. I work with colleagues but mostly on my own stuff, so I get a lot of freedom to handle things.
At a studio I worked at once, two others and myself were assigned to a new project. Since we were the only ones working on the project, we got permission to clear out a storage room and convert it into an office. It was just the three of us in a decent sized room and I feel that my work satisfaction and productivity was double what it was anywhere else in the open plan office space. There were very few distractions,…
Working from home, while having a 10 min daily standup voice call. I work with colleagues but mostly on my own stuff, so I get a lot of freedom to handle things.
Also: a great manager who advocates for my product and career and shields me from politics.
What has worked for me to facilitate my best work is to reserve a meeting room to myself for one or two hour slots during the week. This allows me to close the door, put my back to the window and get focused. What's great about this is this limits visual distractions, restricts uninvited visitors, and reduces auditory distractions (I will usually wear headphones and listen to non-lyric music).
Often I find that I will get more work done in this period of time than I would if I was sitting at my desk.
XP: open office, promiscuous pairing, very little remote work, 4-6 teammates, 2-3 30-minute breaks throughout the day to do whatever, regular lunch n learns, honest retrospectives, continuous deployment, powerful tools (Haskell, Elm, postgresql), daily company-wise “standup” with 70 people that averages 5-10 minutes, bi-monthly team get-togethers to play games and watch movies, regular lunches together, good code rev…
+1 to XP. Pairing removes many barriers to development: * built-in code review * knowledge sharing: removes silos * helps avoids overengineering (few pairs have the same overengineering idea, so you tend to settle on a decent un-overengineered solution) TDD, which I'm not fully convinced on, acts a clock for pairs: one person writes a test, one person writes the implementation, flip roles, repeat. Other XP practices:…
- code reviews as part of a pull request system
- knowledge sharing - design sessions for features to make sure nothing was missed and architectural overviews with wiki documentation.
- avoid overengineering - again architectural “previews”.
Earlier quoted context omitted.
We're large enough where we have a specific DevOps Teams and the Team doing AWS is doing it wrong. If I didn't have the freedom I have now, I would have a very different opinion of this place and be looking for a smaller shop
Your probably not doing "DevOps" if they hired a "team" for it, sounds like ops on aws
Earlier quoted context omitted.
Your probably not doing "DevOps" if they hired a "team" for it, sounds like ops on aws
"DevOps" doesn't mean shit. It's a bullshit term define by who is using it. That team is in charge of kubernetes, and automated application deployment stuff, so they are the team ensures developers can push to production quickly. Which, now that I google it- it's exactly what the "official" definition is.
At a studio I worked at once, two others and myself were assigned to a new project. Since we were the only ones working on the project, we got permission to clear out a storage room and convert it into an office. It was just the three of us in a decent sized room and I feel that my work satisfaction and productivity was double what it was anywhere else in the open plan office space. There were very few distractions,…
XP: open office, promiscuous pairing, very little remote work, 4-6 teammates, 2-3 30-minute breaks throughout the day to do whatever, regular lunch n learns, honest retrospectives, continuous deployment, powerful tools (Haskell, Elm, postgresql), daily company-wise “standup” with 70 people that averages 5-10 minutes, bi-monthly team get-togethers to play games and watch movies, regular lunches together, good code rev…