5 ms·
Sounds like the relationship is dysfunctional in both directions. On the one hand, the employer set up a panopticon in the office, with crappy furniture, lots
by solatic 5y ago
Sounds like the relationship is dysfunctional in both directions.
On the one hand, the employer set up a panopticon in the office, with crappy furniture, lots of interruptions, a crappy office kitchen, no decent food (i.e. needing to bring food from home). Garbage in, garbage out. Of course nobody is happy to sit in traffic to come to an environment like that.
Then we have the author, who has the mistaken idea that the number one most important thing that you do at your job is your directly measurable productivity. Not relationship-building, just pure "shut up and let me sit down and get my work done." Personally, I'd prefer it if engineering work didn't go the way of Amazon warehouse workers, because if "productivity" is the sole metric of an employee's performance, just wait until your employer decides to try and optimize it.
Best of luck to the OP at the dice roll that is the next company he works for.
- Apocryphon 5y ago> Then we have the author, who has the mistaken idea that the number one most important thing that you do at your job is your directly measurable productivity. Not relationship-building, just pure "shut up and let me sit down and get my work done." To be fair, that's been a popular view among software engineers long before ubiquitous WFH was a reality. And programmers are definitely keen on not getting their flow interrupted.
- LQexplanation 5y agoOne small thing : even if available food is decent, some people prefer their own (diet needs, it may be cheaper, etc).
- jeddy3 5y ago> Then we have the author, who has the mistaken idea that the number one most important thing that you do at your job is your directly measurable productivity. Not relationship-building, just pure "shut up and let me sit down and get my work done." Well, the most important thing is certainly NOT relationship-building either.
- refactor_master 5y ago> Then we have the author, who has the mistaken idea that the number one most important thing that you do at your job is your directly measurable productivity. Not relationship-building, just pure "shut up and let me sit down and get my work done." Relationship-building sounds like something my manager would say. And I’d still have to code XYZ, make sure it works, and make a presentation about it. Not sure how relationships help me in a technical role.
- Fredej 5y agoIn many, many ways. Relationships to your fellow engineers help when you're banging out code and need a review or just a rubber duck session. Relationships to the Product Management team means you have a finger on the pulse in terms of where the product you're building is moving. That means you can push back on stupid things, and suggest brilliant things that were only possible because you had the technical insight. Relationships to upper management helps if you have some technical idea that you want to pursue which requires a significant investment. Basically, relationships help a ton if you want to have any influence on the work you're doing. If you're fine just taking whichever ticket pops up and implementing it then sure, you don't need relationships. I think this however also heavily depends on the company and culture you're in.
- refactor_master 5y agoI’m surprised I got upvoted at all, reading over your well thought-out comment. I do command quite some deciding power. But I can’t figure out if it’s my technical skills, or the fact that I’m the only person carrying this project. Pretty sure no one else around me knows what a ticket is. But what irks me is that my entire position feels incredibly ill-conceived. Like I’m not solving any actual problems. And I can’t “do” anything about it, because that would take years of company-wide restructuring. And I’m just not a long-term visionary, like my peers (who all happen to be, let’s say, at a much later physical and mental state in life). That’s why I don’t see how in-company relationships benefit me. I wouldn’t dismiss them in general though, which I strongly came off as doing. But it’s either that, or quitting. The latter will probably happen in the foreseeable future, once it doesn’t look too transient on my resume.
- seanhandley 5y agoAgreed. It's a false dichotomy that one is better than the other. The only useful way I know to think about it is what my ratio of solo focus time is vs time spent communicating with others. There is a place in the world for people who wait for requirements to appear in their ticket queue, code out solutions, then go home, ad infinitum. But software development tends to work better as a collaborative endeavour. As an IC you should expect to spend 70-80% of your time on focus work (either solo or pairing) and 20-30% on communicating/planning/overhead. The writing of the code itself happens in the middle of a much longer conversation and to deny the programmer visibility of this is to deny them context. Designing working spaces to allow this is possible, but easier if you let people choose where to work for 4 out of 5 days a week.
- ehnto 5y agoLike you said, a false dichotomy, but after years of collaborative development with stakeholders, I still want well defined tickets. Things go missing constantly otherwise, people forget they asked for things, I forget they asked me, questions about the task end up lost across four different communication platforms, it's a mess. At the end of a good meeting, I love seeing actionable tickets, I can relax knowing I have all the requirements so far captured and I can get to work as soon as it's time. In between now and then, I can forget allll about it.
- TheOtherHobbes 5y agoCommunicating/planning/overhead are part of productivity. So are 1 to 1s with good managers. But the people who wander around telling jokes and drinking coffee are just socialising and (possibly consciously and deliberately) raising their profile. They're not doing anything of value to others.
- Zababa 5y ago> no decent food (i.e. needing to bring food from home) I think there's just no food at all at the office. Most offices work that way, at least where I live (France).
- Tade0 5y ago> Not relationship-building, just pure "shut up and let me sit down and get my work done." It's entirely possible to build relationships remotely. I'm sort of a job hopper and also work 80% remotely on average, with two-week-long visits to the office. Throughout the years I always stayed in touch with at least one person from the previous projects. Most of these relationships were built entirely remotely and were much stronger than those made during my time at the office. It's likely a question of preference, but it's not like someone working remotely has to necessarily have a "business only" approach.
- ozim 5y agoDo you see where the author is coming from? I believe he is a developer (or even junior) that has a scrum master or some kind of manager and has tasks and sprint points assigned to him. If he does not finish his "commitment" in points in their designated time, people will ask him "why it took so long?" and maybe put him on improvement plan. Productivity is the most important for him and people like him, because that is expected from him and he is measured against that. No one is going to nag about him not paying attention in one or the other meeting. He will get people nagging when he does not deliver. He dislikes things that get in a way of what he is supposed to do. Then we all know you cannot say you did not made your commitment because you had to attend 10 meetings, this will be taken as making up excuses.
- mmarq 5y ago> if "productivity" is the sole metric of an employee's performance, just wait until your employer decides to try and optimize it. Productivity is the sole metric of your performance, it is the job of management to come up with meaningful metrics. If they try to optimise for something stupid like LOC or mouse movements or hours logged, they will get the hell they planned for themselves. The very last thing I want to happen is being judged by how popular I am.