The thing about this kind of thinking is that it not only attracts good candidates but you also get the most out of whatever people you have (or will get)
I'm surprised so many companies fail at this - companies should invest in their employees, unless they want their company to become a revolving door, in which case, I'll be sure to stay far away.
If you're not trying to develop employees and create a culture of making everyone better at their craft, you're not a manager I want anything to do with because you're likely to be a strong cause of failure.
I know generally what I'm looking for in a company, but unless I personally know someone who works there and I'm tight enough with them to get real information, I'm stuck with whatever they tell me plus hopefully glassdoor, at best. And many companies actively lie on glassdoor: I know of two personally.
During the interview process, the company is selling themselves just as much as you are selling yourself.
>unless they want their company to become a revolving door
Maybe they just don't care if their company is a revolving door or not. That is, software isn't the company's primary focus, so they want someone to occasionally deliver software that sort of works and gets some of the job done.
This is an "agile" operation. A few years of "agile", and they'll be burned-out husks. Then you fire them and hire the next round of naive kids.
Another article cited today on HN, from the Paris Review, says it better:
"When you begin programming, one of the attractions is the certainty that you will never run out of things to learn. But after a few years of working in a corporate cubicle under exploitive managers, after one deadline too many, after family and age and a tiring body, learning the ins and outs of the latest library can feel like another desperate sprint on a nonstop treadmill."
You try to uncover X'ism in tech by pointing out ways in which common industry practice Y disadvantage people in group X. But to do this, you had to claim that people in group X would perform worse when practice Y was in effect. Oops! You're an X'ist yourself!
E.g. X = age, Y = working to deadlines/long hours, X = women, Y = speaking up in meetings, etc.
Anyone that hates Agile should watch this and at least be comforted by the fact that the community that came up with agile in the first place do recognize that there are problems and that it has become something different today:
Personally, I've gone from an organisation that was starting to implement what their version of agile was, back to one that has no such thing whatsoever. While I had my complaints about agile, it's sure as heck a lot better than having no agile practices at all, in my experience.
Here's what I want as a software engineer. I want to be respected for my opinion.
If I say that a customer change is a complicated task, I think it's great if my manager engages me and takes me to task on why I think that is -- as long as this is done from a position of respect and not from a position of disbelief.
When I say "We are likely going to have to implement X, because the customer won't give us an answer on it and just like the last feature, they said it was fine not to have right up until the last minute when it suddenly wasn't", I DON'T want the response to be "So, if we don't have to do X, it should only take a few days, right?".
In case it's not obvious, what I'm dealing with right now in my job is management that expects me to be up front with them but can never seem to believe what I say when I am. It's like they take the most blindly optimistic interpretation of what you say, even though that's not what you said, then hold you accountable for what you didn't say when the shit hits the fan.
If I went to my doctor and he said "You need to take this medication or it's 90% likely you'll get sick", most people would think I was an idiot if I decided to decline the doctor's advice, then complained that the doctor didn't know what he was talking about because I got sick.
So yeah, as a software engineer I want to be respected as an expert in my domain in the same way that people generally don't think it's okay to second-guess their lawyers/doctors/basically any other profession it seems than software engineering.
I guess it's time to stop calling engineering estimates an "opinion!"
But yeah, I see the same thing all the time. We say "this isn't going to work unless we do X,Y,Z," which of course aren't done, and then of course things don't work out, and it's our fault. I blame it on a lack of intuitive understanding (and pressure to cut costs, resulting in a RDF).
Most people would understand that a bridge won't hold if you left out all the rebar from the structure, even if it wasn't visible from the outside. With software, though, people's eyes just go blank at some point, and they simply ignore everything and piece together what they want to hear. "X dollars in Y days, got it."
You are reversing authority. It is the executive whose system you are computerizing who needs to state how things should work - and your job to make it work. If it takes longer than the executive thinks it realistically take, if you can't explain it to him in a way that makes him a master of the situation: you are not doing your job.
So even arguing from the perspective of "my opinion must be respected" is, to me, an indicator of your own failings as an engineer. Its always the engineers job to make sure the system they are building, works for their users. Your boss is a user too.
If you have to have an opinion be respected, you haven't been writing your docs. Opinions don't build working software systems - written materials do. So making sure they're read and understood is actually your job, and complaining about others not having respect for this fact, means you're not doing a very good job.
That's a fair criticism and I do find communicating WHY something is difficult, especially to a manager who doesn't code, to be a challenge at times. It is something I'm conscious of and I'm working on. I agree that respect has to be earned.
For what it's worth, I'm not talking about dictating what the customer's requirements should be (as in "That's a stupid idea, I think this is what you should do instead"). I'm talking about "This will take three weeks even though it looks like a simple change because there are still plenty of unknowns" ... "But we have already promised the customer that this will be done in a few days (without consulting engineering), can't you just do it quick and then we'll fix it up later? (but later never comes)" type stuff. Or never being given the time to implement a test framework or refactor and then being criticized because customers find bugs. That kind of thing I find difficult and frustrating.
I understand you. But I still really believe that if you're in this situation, you've lost control of your customer - and this is your job, no matter what. Sure, users are stupid. We know that. But making them smarter - whether its through a smart application, or a smart process, or smart documentation, or smart other-enlightenment processes .. this is the job of good engineers. Strive to be better at educating the user and you will become a better engineer - its just a truism I've noted.
(Not to say it isn't necessary sometimes to get the gripes off ones chest.. just that it should be seen as an indicator of a failure, somewhere, to engineer solutions for the user.)
So... what happens when the client says "I want a database that's C, A, and P" or somesuch, and then just doesn't believe you/ignores you/etc. when you explain what's wrong with their request? Presume "working in another company" isn't an option, because, in your experience, every other company will do the same thing to you.
I understand informed consent—a doctor can't shrug off the responsibility to get the patient informed enough to say yes to what they're doing with a "just trust me." But sometimes what the user is paying you for is, exactly and precisely, to not have to learn X in order to do X.
18 comments
[ 6.0 ms ] story [ 49.5 ms ] threadIf you're not trying to develop employees and create a culture of making everyone better at their craft, you're not a manager I want anything to do with because you're likely to be a strong cause of failure.
During the interview process, the company is selling themselves just as much as you are selling yourself.
Maybe they just don't care if their company is a revolving door or not. That is, software isn't the company's primary focus, so they want someone to occasionally deliver software that sort of works and gets some of the job done.
Another article cited today on HN, from the Paris Review, says it better:
"When you begin programming, one of the attractions is the certainty that you will never run out of things to learn. But after a few years of working in a corporate cubicle under exploitive managers, after one deadline too many, after family and age and a tiring body, learning the ins and outs of the latest library can feel like another desperate sprint on a nonstop treadmill."
You try to uncover X'ism in tech by pointing out ways in which common industry practice Y disadvantage people in group X. But to do this, you had to claim that people in group X would perform worse when practice Y was in effect. Oops! You're an X'ist yourself!
E.g. X = age, Y = working to deadlines/long hours, X = women, Y = speaking up in meetings, etc.
https://www.youtube.com/watch?v=hG4LH6P8Syk
Personally, I've gone from an organisation that was starting to implement what their version of agile was, back to one that has no such thing whatsoever. While I had my complaints about agile, it's sure as heck a lot better than having no agile practices at all, in my experience.
"You cannot have speed without quality. ... You cannot have speed while you are carrying technical debt."
If I say that a customer change is a complicated task, I think it's great if my manager engages me and takes me to task on why I think that is -- as long as this is done from a position of respect and not from a position of disbelief.
When I say "We are likely going to have to implement X, because the customer won't give us an answer on it and just like the last feature, they said it was fine not to have right up until the last minute when it suddenly wasn't", I DON'T want the response to be "So, if we don't have to do X, it should only take a few days, right?".
In case it's not obvious, what I'm dealing with right now in my job is management that expects me to be up front with them but can never seem to believe what I say when I am. It's like they take the most blindly optimistic interpretation of what you say, even though that's not what you said, then hold you accountable for what you didn't say when the shit hits the fan.
If I went to my doctor and he said "You need to take this medication or it's 90% likely you'll get sick", most people would think I was an idiot if I decided to decline the doctor's advice, then complained that the doctor didn't know what he was talking about because I got sick.
So yeah, as a software engineer I want to be respected as an expert in my domain in the same way that people generally don't think it's okay to second-guess their lawyers/doctors/basically any other profession it seems than software engineering.
/Vent is now over :)
But yeah, I see the same thing all the time. We say "this isn't going to work unless we do X,Y,Z," which of course aren't done, and then of course things don't work out, and it's our fault. I blame it on a lack of intuitive understanding (and pressure to cut costs, resulting in a RDF).
Most people would understand that a bridge won't hold if you left out all the rebar from the structure, even if it wasn't visible from the outside. With software, though, people's eyes just go blank at some point, and they simply ignore everything and piece together what they want to hear. "X dollars in Y days, got it."
So even arguing from the perspective of "my opinion must be respected" is, to me, an indicator of your own failings as an engineer. Its always the engineers job to make sure the system they are building, works for their users. Your boss is a user too.
If you have to have an opinion be respected, you haven't been writing your docs. Opinions don't build working software systems - written materials do. So making sure they're read and understood is actually your job, and complaining about others not having respect for this fact, means you're not doing a very good job.
Just my opinion. Respect it or don't.
For what it's worth, I'm not talking about dictating what the customer's requirements should be (as in "That's a stupid idea, I think this is what you should do instead"). I'm talking about "This will take three weeks even though it looks like a simple change because there are still plenty of unknowns" ... "But we have already promised the customer that this will be done in a few days (without consulting engineering), can't you just do it quick and then we'll fix it up later? (but later never comes)" type stuff. Or never being given the time to implement a test framework or refactor and then being criticized because customers find bugs. That kind of thing I find difficult and frustrating.
(Not to say it isn't necessary sometimes to get the gripes off ones chest.. just that it should be seen as an indicator of a failure, somewhere, to engineer solutions for the user.)
I understand informed consent—a doctor can't shrug off the responsibility to get the patient informed enough to say yes to what they're doing with a "just trust me." But sometimes what the user is paying you for is, exactly and precisely, to not have to learn X in order to do X.