6 ms·
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. Eve
by temporallobe 8y ago
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 general sense of schedule but it wasn’t rushed at all. We also didn’t have rhe always-in communication tools like Slack. Phone calls and face-to-face were it. This all made for a very relaxed environment where no one felt rushed and we had time and space to contemplate and concentrate. This is where I learned and created the most. I basically taught myself Perl, Unix (we had SPARC x-terms), Java, bash, csh, ksh, SQL, Javascript and web application development, and so much more, all of which I still remember to this day. I was happy and relaxed and pretty much always looked forward to learning and exploring more every day. Clearly this type of environment works well for some people, and it certainly did for me. I credit these early years to my success. Fast forward 20 years and I am in a completely different environment - open office
plans that encourage collaboration but also distraction, Agile tools that promote micro-management down to the number of minutes you spend on a task, daily stand-ups (sometimes multiple per day if you’re involved in several projects), and constant reporting to management, SCRUM masters and POs. Oh and chat tools. These constant interruptions often make it impossible to truly do creative and deeply thoughtful work. Most of what I do is rushed and measured and we are always analyzing what we can more efficiently and quickly. Responsiveness to messages are also scrutinized. Oh and all the meetings - Sprint planning, retrospectives, reciews, backlog grooming, etc. I estimate that most of what I do these days is a lot of administrative busy work and useless overhead, which is definitely not conducive to doing what I believe I do best - write code.
- arambhashura 8y agoFwiw: I believe it should be “I credit my success to these early years”.
- axaxs 8y agoThis 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.
- rglullis 8y agoIf 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 someone on the team expressed some kind of blocking issue that he couldn't solve by himself, etc) Sure, probably this was more about him being a good manager than the "process" behind it. But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.
- shandor 8y ago> Sure, probably this was more about him being a good manager than the "process" behind it. 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.
- mstade 8y ago> But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted. Why can't it be both? Bad managers can be empowered by a process, just as good managers could be hampered – no? Agile provides so many tools for bad managers to micro manage, so that even if the process itself is well intended it still could lead to hell – no?
- rglullis 8y agoOne of the tenets from Agile is "People before Process". Bad managers will micromanage no matter what processes or tools they have at hand. So, no. Bad managers should not be empowered by Agile. They should be weeded out, by other people first and, failing that, results second.
- quickthrower2 8y agoI’ve recently started a job where my time isn’t measured. My time was measure 2012 until 2018. 3 different jobs. Utter misery. Now I’m having a lot more fun and feel very productive in the true sense of the word. There is still stand ups and slack etc. but I don’t mind that so much. Having a stopwatch constantly ticking against you is the main hell I hate in modern tech culture.
- growtofill 8y agoWere you working for Crossover or similar?
- Volrath89 8y ago(not OP) it seems to me it is now "normal" for remote companies to track every second; is it really as soulcrushing as it sounds? Do you have any real world experience with crossover? (I am seriously considering applying with them)
- thoman23 8y agoIsn’t Crossover a scam of some sort?
- deleted 8y ago[deleted]
- quickthrower2 8y agoNope not worked for any famous companies.
- dahart 8y agoDid you have time budgets or quotas? I’m curious how these companies used the measured time, what made it feel so oppressive. (I have no doubt it feels oppressive, just interested in the details.) When I’ve done contract work, and when I ran a startup, I started tracking my own time. I find it helps me focus and account for my time and understand my own habits. It’s not very good for open problems or exploratory work, other than to find that they take a lot of time. ;) Other than tracking myself, I’ve never had a job that measured my time directly. I had one job that did measure when employees were at work, but they didn’t show it to employees nor set any quotas, they just wanted to understand work patterns.
- johntheme 8y agoI keep reading about how scrum,agile,openspace,slack,oncall,whatsup outside of work has ruined developers productivity and life after work. WHY dont we do something about it? why are we going like cattle to the slaughter house? We are developers right we are supposed to be smart, intelligent yes, we have let this come all over us step by step until we have lost our life. Developers - it's time to raise to the basic work environment, we need space, we need to do our work with focus, and YES we need separation between work and home. If a company needs work-after-work they should hire people for these after-work hours, if messages are sent after work, and it's just this additional answer this mail, it should either be handled by workers who work over these hours or just wait to tomorrow We have let this on us, and it's our duty to bring back the focused work environment and the joyful home environment without interruptions from work or being oncall or answering messages.
- mlthoughts2018 8y agoCompanies would rather hire less-talented, less-perceptive, less-skilled workers if they will express fealty to mandated bureaucratic marching orders, even if it means paying more money, letting projects fail, losing business, etc. Companies _will not_ negotiate things like letting developers have autonomy over the process by which the work is managed and delivered, or letting developers have private offices. This is just standard Moral Mazes 101 stuff. Preserving the property that employees behave like obedient dogs instead of free thinkers is the absolute number one mandate, to the detriment of all else.
- avip 8y agoJust man up don’t answer messages off work and don’t make a fuss about it.
- tcbasche 8y agoSince taking a new developer job about a year ago I made a commitment to not sign into my work email on my phone and it's been great. But yeah, what the other commenter said. Just do it!
- henrik_w 8y agoHere is a counterpoint. I worked with software development at Ericsson for about 10 years before XP and agile came out. I too had a private office, and I recognize a lot of what you describe. While it was nice, it was not a very productive environment. Each release of new SW was enormous and typically took a year or more to get out. The developers had no real idea of how things worked in production. Lots of useless documentation was produced. Later on, RUP and tools like Rational Rose were introduced that made things worse. Basically, things worked out despite the process and tools, not thanks to them. In all my jobs since, I have worked in a more agile setting. By that I mean that the team is small (less than 10 people) and sits together with some sort of product owner. Not private offices, but rooms where only people working on the same thing sit. Frequent releases, fast feedback. Very few meetings, most issues can be worked out in the team. In my view, this is a quiet environment, but occasionally there are dicsussions that you overhear (but that is not a problem). In these types of environments I have been much more productive than I was at Ericsson.
- ownagefool 8y agoI have no doubt you're right. The thing is, you can have development standards that require small iterations that are immediately deployable and this are immediately tested and deployed, without pulling all the overhead of some PMs interpretation of scrum. I often find the power is generally with the wrong people and they promote the things that matter to them at the detriment of everything else. I don't personally believe this is by design, it's just people in $foo management position tend to have the soft skills to make their job easier, when many of the developers often don't. And managers, who tend to control budgets and define departments, tend to give those departments to more managers and there's not a lot of people in the room telling them that a software person should probably run a software team.
- danmaz74 8y agoWhat you describe looks how agile was supposed to be. What the op described looks like a perversion of agile perpetrated by managers who either don't understand why agile was born, or do understand it, but only care about increasing their power instead of getting things done.