I worked in a remote team once helping a company in Seattle (that perhaps had a bit of a jock culture problem). I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.". To be sure to repeat a message like that every four hours in channels like Slack.
Managers read it, my teammates in Seattle read it. Nobody ever helped us (because you know pair programming is so much more efficient if you can have two programmers blocked when you could just have one staring out of the window and typing "help" to invisible people). If at all I would be unblocked after a few days usually the problems was some kind of unguessable piece of configuration that should have been part of the README and/or code, a problem completely unsolvable without knowing what to do. Only then I could continue doing a minor change like updating a CSS file for the next Safari or IE quirk, usually just 5 minutes of work.
Apparently helping remote teammates to get unstuck in their work just wasn't an interesting performance metric.
Until this day I still can't believe that everybody was just throwing tens of thousands of dollars of work out the window because helping stuck teammates wasn't counting towards some kind of bonus.
On the one hand it is indeed disappointing that nobody would help you with this. On the other hand, there's a more pro-active role you could have played yourself in this as well. "When everybody is responsible, nobody is" - what often helps is specifically asking people, by name, to sit down with you for a bit and help you get through it.
In fact, there are many social group situations in which asking specific people is far more effective than asking questions "to the group".
If a manager of some kind were to notice the Slack messages and ping someone specific to help, that would be a perfect example of the kind of management that is so sorely lacking at so many companies. Many employees are too burned, or proud, to even put out an SOS... so a cry for help is actually a gift to management. If only it were someone’s job to think for a few minutes each day about each employee and notice if there is some small action that would help them.
Nah, let’s just alternate between micromanaging and being totally absent; fret about lack of productivity or lack of progress; maybe institute a daily stand-up.
Why not both? I cringed when I read OP's comment where he spammed "I'm completely blocked" in the chat without asking for specifics. What a complete lack of individual ownership. Even the best manager can't help somebody who is unwilling to help themselves.
> I cringed when I read OP's comment where he spammed "I'm completely blocked" in the chat without asking for specifics.
You actually expected that what I wrote was a literal quote from the only thing I ever said during those days? It probably was something more like:
"Tried to run project X but kept getting error Y. I tried to figure out where it comes from but it seems to missing some kind of value it pulls from somewhere. Tried every step in the README and installed twice. I think the information in the README is incomplete and there's another step. Nobody else had to use this repo before here so the guys here can't help me out either. Can you help me out @colleagueFromTheUS1 or @colleagueFromTheUS2?"
After 48 hours I get very specific about being completely blocked and that I have exhausted every way thinkable to get it running. So nobody would be living in the fantasy the problem was going away by just ignoring it long enough.
One of your jobs as a manager is to debug these people issues, right? So when you get a "bug report" like "I'm stuck", you should investigate the bug and look for a solution, which might be something like "Hey Bob, Jim is having trouble getting the Frobnicator running on his machine. Can you please give him a hand with this later today? Thanks". (This assumes that Jim's SOS was issued in the first half of the day; want to make sure the issue gets resolved promptly while also not interrupting Bob's own productivity/flow.)
Yes that's true, which is why I said "why not both?" The manager should do more, but so should the employee. Sitting there and saying "I'm blocked, woe is me" is garbage compared to saying "I'm blocked. Can you please help me Mr/Ms XYZ?"
I think your specification of a "correct way to report a problem" is company specific, or your personal preference, or the way that you think an ideal problem report would be stated.
We're humans. Unless there's been a training day or a Readme file explaining HOW to report a bug, I think it's perfectly reasonable to expect this protocol to work:
"I'm blocked!"
"Why?"
"{reason}"
If nobody ACKs the "I'm blocked" message, it's reasonable for someone to think that nobody cares or nobody is listening. This is a normal human protocol, as used in most human environments.
"{problem}!"
"What's happening? How can I help?" (any considerate person nearby responds)
You will get a lot of downvotes for making that statement here... but let me just say I agree with you 100%. The people I see that get the most work done aren’t the ones crying publicly for help on a nebulous problem, but asking very specific questions about specific problems. In cases one doesn’t make progress, escalate to the manager giving details about exactly what is going on, how many times you reached out to another team and got no answers. That gives the manager ammunition to talk to their peers on other teams or escalate to higher ups.
It’s rather unrealistic for the manager to be understanding all the time and coax a team member to give all details of every problem...
That's how I was taught (via managers on reddit actually, not irl).
Dig as far as you can, record it all, then escalate. You also have to gauge how critical it is and how much of your time (esp. if other things are building up) to spend on it as a factor of when to take it up the line.
Tbh, I haven't had any managers lately that have been that great but I'm still holding out hope.
I agree with you that employees that you cannot trust should be fired. Skepticism doesn’t necessarily mean lack of trust. It’s possible to trust dishonest people and without a skeptical view to be aware that people may be dishonest, even in small ways, it is easy to fall into that trap of trusting good liars.
> As a manager, are you prepared to put your real name to these comments?
This is an anonymous public forum with a massive audience and great content. Let's keep it civil and not target individuals. Please don't try and start witch hunts to ruin someone's career just because you do not agree with him.
A new repo, likely a new employee on a new project. I have to disagree with your statement since you don't know the context at all. If all they're given is a repo with inadequate instructions, there's not much more you can do than keep asking for general help.
Comment sounds like typical 'pull yourself up by the bootstraps', meant to put down new talent, ignoring that complex, modern dev environments have many parts that are completely out of reach for newcomers without adequate onboarding.
Like you said, why not both? The employee is already asking for help, that's their part. The manager needs to come in and assist, unless he enjoys churning his dev team.
> I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.
That is not asking for help. Asking for help would be "Can somebody please help me? ... rest of message here...". Even better is asking an individual (or individuals) directly.
Nonsense, this is asking for help. As a former manager of a tech team, if I had seen this I would've taken action, and as a team player individual contributor I would've taken action even if I were not a manager. I appreciate you sharing your perspective, but in my opinion you're leaning too far to try to find some way to blame this employee for processes that an employee should reasonably expect a competent management team to have solved already.
Say what now? Mentioning you are blocked, in a stand-up, multiple times is a cry for help. What is the point of having stand-ups if you're not assisting blocked team members?
He mentioned that he brought it up in the standup. The standup is when you announce blockers. Was no one else in the standup listening when he said he was blocked? That's when someone goes oh here is what you do.
The standup is for blockers to be announced. It's the 3 stage of the standup.
Sounds like poor management, don't blame the new guy, he did say he was blocked in standup. How is he to know who to ask. Whose time can he impinge upon. It might be he asks someone who helps him but he gets in trouble because he now took up that persons time from something else.
The manager should see oh he is blocked, I'll assign so and so to help unblock him.
This person probably DID ask more specific questions. They were just describing the gist if the interaction. Not a literal copy paste of the exact messages.
Having my blockers completely ignored for a significant amount of time was a major factor in deciding to find a new job. There are only so many times you can beg for libraries, source code, permissions and other essential tools before coming to a conclusion that maybe somewhere else there is a place where you don't have to deal with this bullshit.
When someone under-performs, I always look at who they report to. Nobody wants to perform poorly. Typically the lead / manager has given inadequate guidance, or there is a serious skill set mismatch, both of which are on the lead / manager.
You should stop being a manager. Or get training to become a better one. Seriously.
When a member of your team can't perform because he's not given the proper
resources(access, help, info, etc), it should be your number 1 job to find out
why is that the case and do everything in your power to rectify that.
I don’t see the reason to assume that was litterally the entire message posted to the channel, it seems more likely OP just pharaphrased what they actually said when the made that commen on a public discussion board.
Nitpick s/he said s/he couldn’t run the repo. If someone posted that in our slack someone would jump in and ask what errors s/he was getting. Once we found a solution we would get the docs updated, usually by the person who found the problem since they have the most context.
People ask for help in different ways based on personality, skill set and experience. It’s more important to meet them where they are than sit back and smugly suggest they lack individual ownership.
Could you please give an example of a message with more ownership? Keep in mind that he didn't know at the time that he was missing some undocumented configuration step.
What kind of company or culture is that, when someone asks for help from a group
and no one volunteers to even suggest to them a person that would be the best candidate to help them?
I've never been at such a company and I hope I never will.
I've worked at different companies that just culturally have very different approaches. Where I am now, I will basically corner people until they help me or provide a better option on where to seek the help I need. At my previous employer, there were certain mailing lists where you could ask questions and if your questions reflected real effort, you could expect helpful responses.
This is similar in emergency situations. When you need somebody to call 911, don't ever say "Somebody please call 911!". You have to look at someone, point at them, and tell them "I need you to call 911". Most people will either stand in shock or think that someone else is on it.
> Most people will either stand in shock or think that someone else is on it.
The bystander effect is real, but I wouldn't expect to see it in organisations with explicit hierarchies. Can you imagine this happening in the armed forces? If this happens under your watch as a leader, you're not good at leading.
It occurs in explicit hierarchies all the time. Watch the opening scene in "Saving Private Ryan." Most of the troops are scared shitless, waiting for someone to tell them what the hell to do. And these were troops who had been trained for 3 years before hitting Normandy.
I like that the problem is remote specific, and the first image you have is “asking people, by name, to sit down with you”. Your image is nit wrong, but a symptom of how we can be hardwired for physical proximity.
Otherwise, a common issue for a team with colocated workers mixed with remote workers is a facility to ignore calls and messages.
Central people get easily overworked, interrupted and drown into tsunamis of requests. One of the coping mechanisms in these situations is to just ignore most requests, and only deal with people getting loud enough to be heard. In a mixed environment, the coworker siting 10m away has an easier time grabbing attention than the icon in the chat room with a unread badge.
Even simply knowing when someone is taking breaks can help to time requests to get them at the right moment.
I have remote days every now and then, and it’s interesting to see how the game is completely different, and how often I end up asking someone physically there to go talk to people on my behalf.
I agree that remote is more difficult than physical, but it's still much easier to ignore a general comment in a chatroom than one that's specifically addressed to you. Most chat applications will even highlight lines mentioning your name.
(Note that being remote in an otherwise physical team makes this significantly more complicated as well.)
It's good you pointed this out because many people don't know. I took a first aid class and they taught us in an emergency situation, never say "somebody call 911!" Because everybody will think someone else will do it. Point to a specific person and say "you, call 911!"
This is a big challenge for remote employees. At some point when do you just give up and settle for what you can get done and not worry about what you cannot change. Its a poor attitude but it happens at a lot of companies.
What makes my stomach turn is the interpersonal aspect. How can all your teammates see you fail through no fault of your own for days and pretend they don't notice. Unfortunately in my experience, that's not a rare occurrence.
I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck. Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done.
So if there is a micro-crunch coming up (i.e., I need to have an SOP drafted, tested, etc by this afternoon), the entire morning I tend to blow off other peoples issues. Until I can get a chance to come up for air.
But that makes me feel bad, so what I end up doing instead is I go home at the end of the day and work till past midnight just to get caught up on what I couldn't do in the daytime. For any outside-the-box work I tend to pull 20-30 hours stints over the weekend. After 25 years of this, and as I need more sleep since I'm getting older, I can be a bit snippy when someone breaks me out of my concentration because they can't figure out something, and they have a down customer that needs service "right now".
It is also easy to get irked when people are seemingly unwilling to do any digging or reverse engineering on their own and go straight to asking for help. Allowing someone to search for an answer for several hours may seem like a waste of their time, but it also could allow them to learn how to figure out a problem on their own. Of course their is a fine line between being a jerk and not helping someone because you want to maintain your technical superiority and not helping someone because you want them to learn how to problem solve. Clearly you do not want to leave someone roadblocked for 48 hours when they are trying hard and you know the fix is some stupid bug. But, it's not always super straightforward either.
Yes. Unfortunately, by the time you start to think people are asking for fishing lessons just to get lunch, it can become difficult to recognize a true student.
I started out as the eager mentor, even when it was among my peers in university. But somewhere in my ~25 years of R&D, I started to notice how coworkers would become dependent. They would ask for help on types of things that I knew I had figured out myself, even when I was a novice. They develop the plea for help as a first reflex to avoid any learning tangential to what they consider the task at hand.
So, I found myself swearing under my breath and refusing to be their search engine or man-page. Depending on my mood that day, I might tell them I have no time and they should google it themselves, or I might pretend I don't know the answer either. Sometimes I relished the time to sarcastically school them on the mundane deductions it would take to answer their question from the very screen full of error messages they pasted at me. But, I already knew they would miss or ignore the hint, and be back again next time they stumbled.
Sadly, I think this cultivated impatience leaked out into my attempts to mentor a very junior staff member we had a couple years ago. I could no longer really distinguish "too lazy to try" and "drowning". They found a new job after a year or so, and it was probably wise for them. I am still trying to visualize how I can do better the next time we try to onboard somebody far junior to our current team...
I struggling with this constantly. If I have to fix another VPN issue caused by weird DNS server entries in OS X I’m going to scream. “Anybody else getting this error?” No, figure it out. I’m at a loss to explain how so many people wind up in software dev roles while lacking the most basic of problem-solving skills.
Capability and responsibility become conflated very easily. You start off as the superhero who can fix problems, but that gradually creates dependency.
1st year
'Thanks for your help finding that error that was holding us up.'
2nd year
'We are all finished now. Just sent it over to you for debugging.'
3rd year
'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management
4th year
Management: 'we need to talk a about the regular delays here. We have several teams waiting on you. Also your own code checkin's are much lower than theirs. Seems like you are only making changes to what others write.'
Managers inadvertently create this dynamic when they are focused on attacking obstacles rather than creating infrastructure. If <employee> knows how to do something, and that thing is not getting done, then <employee> is the obstacle. The discussion often doesn't make it to the point of 'why doesn't anyone else know how to do this?' Management needs to think more like logisticians rather than tacticians.
From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now <Peer's> inability to properly take notes or retain information. <Peer> knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally <Peer> will have better knowledge retention by synthesizing their own notes.
Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.
Start by actually talking to your management instead of just trying to be a rock star. "Hey, I'm spending a lot of time doing Team X's job and it's impacting on my assigned work, if you want me to keep doing this then put me in charge of Team X, otherwise let's all sit down together and clarify who is responsible for what."
So I'm asking this not to move the goalposts, but because it's the situation I'm in - what do if your manager is too weak/distracted/uncaring to actually act on this information and/or the projects in wait state on you are not actually within your manager's sphere of influence?
Hmm, tough one. The default answer is "follow it up the chain" - if your boss isn't doing the right thing, talk to their boss, and so on. Another approach is to talk to the manager of the team who's leaning on you, and let them know (if they don't already) how much they're depending on you and that you should really be in that team. This can cause drama with your immediate boss (they're seen as 'poaching' you) but if said boss doesn't care then this might not be a problem.
Of course, by the time you have upper management yelling at you because "several teams are waiting on you", the response becomes "why have you allowed several teams to become completely dependent on one overworked person?"
The other, more drastic solution (as someone else said) is simply to move jobs. This can be the only way to fix the issue if the entire management structure is corrupted and you don't think it's fixable from within. You could even just leave, start a consultancy company, and let the second team know that you're available for hire when they need you.
Unless something is keeping you there, just find a new job, here are some reasons:
- If you reach this situation, you're more competent than the rest of the group. Nobody to learn from, time to go.
- "Management" is a big machine, with its own insider culture and politics. It does not change overnight, do you want to wait 6 months minimum for things to get better?
- Changing job is good for just about everything: career, money, knowledge... as long as you don't do it too often.
- Meta-bonus: getting into a job with better peers means tighter work-friends. It's not fun to be around people overdesigning object-oriented projects when you understand functionnal programming and low-level debugging.
That's neither healthy nor sustainable. You're the one that sees a problem; you absolutely need to make your boss aware of that situation and that the company needs to arrange for better utilization of man-hours. If management doesn't fix that to be healthy, consider moving to a healthier position.
Just to try to put this in a (unfair to you) constructive context:
> I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run.
>> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck.
This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc.
That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc.
Partly this is because I really cannot be bothered to keep such details in my head, anyway.
> Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done.
Honestly, there's not much you can do if you feel like your company is not acknowledging work that you believe is a valuable use of your clock time.
What I notice more senior people do is 1) expose clear SLAs to require their help and 2) get in the habit of producing more artifacts while they concentrate so they can refocus faster after an interruption.
I'd best describe myself as a "computer person". Other than the first few years when I first started at around 15, my job has been Unix Systems Administrator / Engineer, but I've always thrown a lot of programming at my job too. Not just systems automation programming, but various utilities, apps, etc.
For example, back in 89 (I was 18 - 19 then) the company I was at had a need to access multiple screens at the same time in their green-screen (serial terminal) application. So I wrote a multi-session terminal emulator. Ended up being a lot like what GNU screen is today (not sure if screen existed then, this was pre-internet days for me).
Other times I'd write up software distribution systems, monitoring systems, etc. Or work on creating things like a custom interpreted language, just because an app developer at my company needed that. Or write hand-coded postscript, because someone's app needed that.
In my current company, I'm still a Linux systems engineer / Lead, but I've been on-loan to our app development team to help with C-based libraries that they need (this code is a couple decades old, and they don't have any C hackers that can work on it). This is software that interfaces with medical testing equipment, so it feels like I'm making some difference.
Lately I've been brushing up on my web development skills, becoming buzzword-compliant, and putting together web apps both for internal use, and related to maintaining our product.
I guess I should have went into full time development years ago, but I was always worried that I'd get shoved into boring business applications instead of working on really interesting stuff. So I've stayed in the Unix/Linux ops role, found out that a lot of what I've been doing is now called DevOps, and doing open source work on the side.
As for the trajectory, I haven't changed jobs that often. I've had a couple of dud-type jobs where I lasted 1 - 3 years (they didn't want someone who could do "extra" stuff, because that "made the rest of the team look lazy" as I was told in a performance review once). But when I start at a good place I try to make a good first impression, then a better second impression, and try to work and support as many people as I can (while doing my best to make them look good, but making sure I get recognized too). Helps to have a number of people that "have my back".
I've actually slowed down a bit in recent years, however the main driver is that the work is fun. During the day I do the necessary (but not necessarily fun) work. After hours, I work on stuff that is mentally challenging and needs concentration, but only if I find it fun to work on. I do this instead of watching TV for example. As long as I get in enough time for other activities (hiking / bicycling, woodworking, designing my own creations, time with family) then hopefully I have a balance. But I have always had a slightly unhealthy fixation on sitting in front of a computer screen and creating (whether I'm doing it for work, or personal projects).
Having been the 'goto build guy', I've had to cut people off who were seeking me out for very self explanatory issues. For example, when the build threw an error because it couldn't find a file, pointing out where in the error to get the file, but the person seeking help didn't even try reading the error. Basically I limit my intervention to prevent enabling helplessness. The amount of help given also depends on the role of the person as well, junior devs get more hand holding then senior devs.
This to me sounds like a complete lack of self-ownership on your part. You literally sat blocked doing nothing for days, without reaching out to an individual to help with this? Instead you just spammed Slack saying you're blocked?
While I agree that it would have been nice if somebody helped you, you are in control of your own destiny. If nobody is helping you, you need to personally escalate it and reach out until you get the job done. If somebody did this on my team, the first question I would ask them was why the hell they let themselves sit blocked for days.
...and of course my team would have been more proactive on helping you because one of our core values is help your co-worker, but that is besides the point here.
And even if everyone completely ignored them when they direct messaged their teammates... why do nothing. Why not dig in and figure out how to get it to build and update the Readme? I don't understand why someone would just sit there and do nothing instead of trying to fix the problem.
I did that once and then rewrote the repo. Everything was fine for months on our team until another team merged their exact copy with new changes that broke what I was doing. Everyone senior left my team and it looked like I was doing nothing for 4 months. Communication should come first and the manager needs to step up.
I agree that communications is important and was the primary thing wrong here. It was more that even on top of that, they just sat there doing nothing vs. at least trying to be productive and figure it out for themselves.
Sure I have backups. The other group took a copy of the repo and changed it over a three month period and never checked back in. The versions were very different and merging my copy in was difficult and required a rethinking and rewrite.. in the end it became three separate components. All of this happened during a management change so the timing wasn't perfect.
It also appears to assume that someone could help them. There are plenty of times where knowledge of a project or component is simply lost, either the developers don't remember or are gone, it's one of the costs of employee turn over.
OP said slack. DM is as simple as doing "/msg @joe.blow I'm blocked, can you please help me?". If no response, go to @joe.blow's colleagues. If still no response, go to their boss. If still no response, go to their bosses's boss. Repeat until you run out of people to escalate to, at which point you find another job.
If they are willing to pay a blocked remote worker for sitting on their ass doing nothing, why should the worker rock the boat so much that they burn all bridges at the company and finally have to get a different job? Remote jobs seem somewhat hard to come by and can be a sweet deal.
The company needs to take at least partial blame here.
No need for worker to do that. But that's then their conscious decision and they shouldn't express their frustrations over it. On the other hand, if they want to make a progress, they should escalate appropriately.
Note that I am not convinced that this is the case here - I simply don't have enough information to make the judgement.
So someone wanting the system they are a part of to work appropriately without them having to be an excessively aggressive asshat about it needs to swallow their frustration entirely and not even vent about it on an online forum?
Even!more than that, at some point you start including "You are paying me $xxx/day to do nothing productive because I'm unable to get 15 minutes of time or even acknowledgement of requests from persons X, Y and Z."
My other thought was to file blocking bug/defect issues on the relevant software because obviously if it can't build in the first place it's certainly not passing QA.
Some of this may get to the level of passive-aggressive or aggressive-aggressive bridge burning.
> Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.".
This happened to me once a few years ago, once I finally figured it out I put all this silliness into one single bootstrapping function you could call to get the pig of an application to run, and asked the lead dev to add it to the core library. Later that day I got called into my manager's office as apparently my behavior was disruptive and problematic.
Maybe it's not the initiative per se. Did you name the function silliness(), runPig(), or give any other blatant display of contempt? It's dripping from your comment.
(not saying it was necessarily about something real, just that it could be)
Nope, any contempt would have only been after the other developer displayed his contempt for productive use of shareholders money. I always find it funny how so many people seem to think that is a matter of opinion rather than a matter of fact.
This is endemic to our industry. The problem really is short-sighted management. They only value something that shows themselves in good light with their superiors.
Managers absolutely don't seem to care about actually building a team and cultivating a culture of success.
Engineering managers are way way worse than Soccer managers in this regard.
I would put this all on the hiring processes right from how we hire engineers and managers and what gets a promotion. But unfortunately, our industry would rather remain blind.
The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.
Often the non-technical reasons are "management doesn't want to assign the super-lead to the work, but also doesn't want to let the new hire have free reign to rewrite a legacy product. Just fix it."
I've often wondered whether this dynamic is exactly the reason tech culture is ageist. If we hired older developers, the culturally-assumed "gravitas" of age would make their relative social status to more-"senior"-but-younger devs illegible. We might actually have to sometimes give them the right-of-way on making the changes they want to make, even though they're new!
Every company I've worked at for software development has had review / feedback opportunities for my manager. I can't imagine working at a company where feedback from direct reports wasn't a major factor in someone's job performance evaluation.
Then again, I've been very selective in where I work. People like to bash the "culture" stereotype, but it's definitely something I consider when I'm looking for a job... you know, how people are expected to interact with other people, not whether there are ball pits and the like.
I don't think it's specific to our industry. I think it's specific to the corporate system we have, and that it correlates with the sense of ownership and freedom that we give people. When it's "every man for himself", you're going to see that optimization toward individual metrics and protection of personal reputation, even if it means that a colleague's reputation is deprived.
When you have a recognized long-term leader that doesn't need to constantly re-justify their involvement and existence (something akin to a BDFL), more collaborative group efforts can be fostered, and individual gamification is much less useful, because the people who know your behavior are going to be there for a long time and there is a lot of personal continuity. This system is, of course, not without its own type of flaws, but it doesn't have the same negative feedback incentives for individual contributors.
It's hard to get that long-term involvement in the tech industry specifically because the rapid rate of technical change limits career length and portability. Skills in language/system/framework X rarely retain marketability for more than 3-5 years. Most people don't have the stamina, interest, or whatever it is that's needed to keep up with the constant re-education and re-justification cycle into their 40s and 50s. They look for an out: early retirement, promotions into non-coding management positions, etc.
To the extent that individual metric gamification is higher-than-normal in tech, I would attribute most of it to the effect of shorter career tenures, both overall and at specific companies.
I think short-term thinking by superiors causes short-term behavior by reports.
If the management pays fairly, with fair raises, fair balance, fair acknowledgement of all kinds of work and not just the flashy stuff, most reports would focus on the right things, do their jobs well and not look to switch jobs all the time.
But if the management is always trying to escape giving promotions/raises, does not acknowledge the underlying effort to get something to production, only thinks about their own empires (basically short-term selfish thinking) it will cause a disproportionately high number of reports to behave the same aka look out for their selfish interests.
I am absolutely certain that top companies look to retain good players (top != stock price or market cap).
I can't say for sure but your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it. If people aren't helping you then according to their cost benefit matrix it isn't worth it. Maybe they are supposed to be doing other work and they can't calculate how many hours they would have to spend helping you. Maybe they are just afraid of not knowing how to get it running either and will get entangled and implicated in what is currently YOUR ignorance alone. (I've worked with plenty of these crappy apps with undocumented dependencies where if you get the AUTHOR of the repo to try to build THEIR project on a machine other than their own it craps out on them in which case they fucking bail or defiantly say 'it works on my machine'. These same people will snort derisively if any junior tells them of problems building their project, with a line like 'its not rocket science you know' -- until you confront those mofos with the demand to actually build their own fucking project. At that point you discover that not only did they not document all their dependencies, but they can't even read a simple node error message complaining about how node-sass is not defined, because their project depends on node-sass being globally installed and they didn't realize it themselves.)
>your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it
pfft. If it's a web app (from 2015-2018) I have even more sympathy for the OP than on any other platform.
Here's an example from last year-ish:
* Get repo from external contractor (let's ignore the 1+ weeks trying to get an install of Git approved)
* Try to get npm working - can't get through our firewall
* Figure out the right chaining proxy to use
* Spend a non-zero amount of time trying to work out all the right bits to flip to turn off ALL SSL verification from npm because interception proxy
* Hit the Windows MAX_PATH limit and have to spend ages trying to delete files that NPM's created (original developer used Linux)
* After npm starts downloading stuff correctly, suddenly it needs a binary dependency (and thus more build tools)
* Give up and check in said binary dependency from elsewhere
* Finally build all the CSS and minified Javascript and check it all into source control with a warning to other devs not to rebuild it unless absolutely necessary
> I can't say for sure but your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it.
Not necessarily. In my case, we have a web application where it eventually turned out that the variable was read from an environment variable. On a server where I didn't have access.
Isn't the Toyota's idea of Kanban supposed to alleviate this? As in if there is some problem with the production line, anyone can push the stop button, and everyone assists?
Just to clarify your point, I believe you are referring to andon[0], the system of alerting people to an issue, rather than kanban[1], a system for inventory management.
In a manner of speaking he did pull the andon cord by speaking up in his team meetings and alerting people in Slack, but the cord means nothing if there is not a culture supporting the alert.
No, the equivalent would be as soon as he raises the issue, no one can type even one more line of code, not even a character, and their editor would be completely blocked.
That’s what these companies need. The entire business comes to a screeching halt.
And if they really needed more motivation, production servers could be shut down if the issue was not resolved in 24 hours. That will really hold their feet to the fire.
There are other issues at play when it comes to helping out remote team members.
When you're co-located with someone you develop better comradery with that person. You'll know them better and they'll come right to your desk when they ask for help so you're more likely to help them. And you sit with them as they execute commands so you can see exactly what's going on.
remote coworkers are easier to ignore, harder to help, and harder to socialize with.
I have generally chosen to deal with this problem by refusing to acknowledge the existence of bonuses or promotions. It is harder for a warped incentive structure to warp your behavior if you refuse to be motivated by its prizes.
That's noble, but many aren't inclined trade personal profit for the company's profit. I don't think they should be, either. It's the company's job to ensure that their success is aligned with their employees'. Raise the issue to management, and if no action is taken, then you've done your due diligence.
I can imagine situations where you should care about the company's performance, like a non-profit or certain startup situations, but I think the majority of enterprise developers fall under the above.
> I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.
Certainly it might've been more efficient if one of your colleagues helped you debug the issue. But in the absence of help, it's not clear why you didn't dive in and start debugging on your own (rather than doing nothing). You'll learn more that way too.
That's not really undebuggable. Process Explorer shows registry calls, and IIRC even marks them in red when the key is missing. Again not arguing that this is efficient, just that doing nothing is less efficient.
I generally assume that when someone says "blocked" they're not literally staring out the window, they're just not operating with anywhere close to the efficiency they should be.
Also it's not clear to me that learning how to use Process Explorer + using it, when that's not your job, is actually meaningfully more efficient than staring out the window all day.
If learning to use Process Explorer can aid you in performing your job duties, then I feel it would definitely be more meaningful and efficient than just staring out the window. I can't judge OP's situation because I don't know all the details, but I think there is something to be said for being willing to dive in and "unblock yourself" like some people have said. There's obviously a gradient between being helpless and the situation being genuinely out of your hands, though.
I think the point was that it's silly for someone who's meant to be on a team to spend possibly days trying to debug something as silly as that, instead of someone on the team just spending the few minutes to help them and give them the registry key they need.
It's not time efficient for everyone to work separately down to reverse-engineering the machine code to work out what's missing every time.
Are you a junior dev or was the work in a domain unfamiliar to you?
If not, you should be able to at least start debugging. You should get some error message (maybe that indicates some env variables not set, something not installed, etc). It seems odd to have not spoken directly to your supervisor or product owner to say "hey, this isn't working because X. What do I need to do / who can I talk to for help?"
Most jobs I've been at if you're the first new hire in a while you are going to experience something like this, and it's important that you spend a lot of time adding to the documentation to make it easier for the next new hire.
Managers read it, my teammates in Seattle read it. Nobody ever helped us (because you know pair programming is so much more efficient if you can have two programmers blocked when you could just have one staring out of the window and typing "help" to invisible people). If at all I would be unblocked after a few days usually the problems was some kind of unguessable piece of configuration that should have been part of the README and/or code, a problem completely unsolvable without knowing what to do. Only then I could continue doing a minor change like updating a CSS file for the next Safari or IE quirk, usually just 5 minutes of work.
Apparently helping remote teammates to get unstuck in their work just wasn't an interesting performance metric.
Until this day I still can't believe that everybody was just throwing tens of thousands of dollars of work out the window because helping stuck teammates wasn't counting towards some kind of bonus.