11 ms·

Culturally transmitted skills and values

205 points by ramimac 5y ago

oreally 5y ago
> Culture: people enjoy building complex systems and/or building complex systems results in respect from peers and/or prestige Seems great for architecture astronauts. Maybe they'll stay long enough to eat their own crap. In the meantime, I'll keep in mind to stay away from such companies.
- bhouser 5y ago
  In case it didn’t occur to you: I think this was put forward as an example of culture producing negative outcomes.
  - m0zg 5y ago
    Dan is actually referring to Google where "complexity" for a very long time was an explicit requirement for career progress to Staff level and beyond. I bet it's the same way even now, unofficially. For better or worse, engineers do not seem to sufficiently value simplicity, so people hated the rules, but played the game, producing insane rube goldberg like backends all over the place that you need whole teams of experienced SREs to run successfully. The fact that this is ridiculous was not at all lost on people either - memes on Memegen (an internal meme site) were pretty vicious. But, not a heck of a lot you can really do if you want those golden handcuffs to turn into platinum ones. I'd be remiss if I did not mention the silver lining in all this: Google's SRE team is very likely the most experienced in the world, and SREs are respected there. Stuff wouldn't run at all if this wasn't the case, and certainly not with five nines of reliability. Another bullshit requirement in the general case is "cross-team impact". No matter how valuable you are as an IC, you gotta get a bunch of other people involved so they write your peer feedback and endorse you for a promo. Sometimes this makes sense. Often it does not. And those people better be one or two levels above you, which is a problem in a remote office. There was a whole slew of antipatterns like that which might have made sense at some point in the past, but now are perceived as an immutable thing nobody can do anything about. So in a way, "culture" is not necessarily an _universal_ good, although at the time I was there the good outweighed the bad IMO. This cultural stuff is also why Agile by itself does not mean you'll be particularly "agile", nor is Agile required for high agility. As a manager I've found that if I can get people to care about things and give them autonomy, most of them will not require close supervision and will move faster than they'd otherwise. Some will require supervision, reminders, incentives, and all that, and those are best sequestered from the rest and grouped with folks with similar working styles and put to work on tasks that tolerate that kind of thing, or in clinical cases let go.
    - comlooogler 5y ago
      It is the same now, and officially so. One of the dimensions for perf/promo is complexity.
      - kevincox 5y ago
        IIRC it is still for "Software Engineers" but it has been replaced with Simplicity for "Site Reliability Engineers". Of course just changing the written rules doesn't change everything, and it creates an interesting friction.
      - m0zg 5y ago
        Sadness. There was a period of time when upper management knew this was a problem and tried to do something about that.
- emodendroket 5y ago
  I would hope nobody wants complexity for its own sake, but I do think there's something to be said for not shying away from a problem just because the only way to solve it is complex.
roca 5y ago
Incentivizing people to create complex systems sounds really scary to me. I guess there's an implied "where the complexity is absolutely necessary", but anything that approaches rewarding people for complexity sounds to me like one of the worst things you could for a software development organisation.
bawolff 5y ago
> Process: don't allow anyone who's late into the meeting Amount of people being late goes up once they realize they can skip stupid meetings simply by being "late"
- bsder 5y ago
  I have no problem with this, actually. If only people would actually take advantage of this. One the banes of good meetings are people who don't belong in your meeting but whose feelings will be hurt if they aren't invited.
  - bopbeepboop 5y ago
    I quit a job because a manager made it insufferable by insisting he be invited to every developer meeting, then interrupting with useless tangents and requests people explain things to him.
- ralmeida 5y ago
  Fair enough, but in many cases some attendees attend only by inertia and would be better off declining instead anyway. Which is probably good overall if the meeting is indeed "stupid".
- wence_ipon 5y ago
  As someone whose calendar is often wall to wall, this is really stupid. The fact that I'm two minutes late because I'm a biological creature and need to piss occasionally doesn't mean I should be excluded from critical discussions.
  - dexterdog 5y ago
    That's why all meeting should end at least 5 minutes before the hour or half hour.
    - analog31 5y ago
      They should have Bells, like school.
8note 5y ago
That process solution for getting people to meetings on time. I'd expect the meeting times to be changed to have more affordances for say, going to the bathroom between meetings, or the elevator being busy. A proper process solution says that the process is the problem, not the people using it
- tharkun__ 5y ago
  I see Google tried to 'address' this by having an option to make meetings go 5 minutes less than the "full" standard length. 30 minutes becomes 25, the hour meeting is 55 minutes. My experience, which matches exactly what I would expect from a technological solution to a people problem: Nobody cares, meetings still go 5 minutes too long instead of ending 5 minutes early. If at your company nobody keeps the time to the regularly scheduled time, nothing will change! It takes people actually keeping the time box of the meeting to change any of this. Be the guy that says "2 minutes left" 3 minutes before the end of the meeting. End your own meetings early by saying "running up on the time box, 2 minutes left" when it's 5 minutes to the end of the meeting and actually ending it. If nobody does that, nothing will change.
dan-robertson 5y ago
These examples at the start are great. I read the first thinking it was a bit silly and contrived but it worked super well to prepare for the second which was succinct but sounded familiar and then the third which sounded relevant to businesses but more positive and constructive than the first two.
itsmemattchung 5y ago
> debug a bug that takes more than a couple hours to debug because engineer time is too valuable to waste on bugs that take longer than that to debug, an attitude this person picked up from the first team they worked on Depends on where you live in the stack and the impact of the bug. Critical bug causing customer impact? You bet you are going to have tons of (senior) engineers jump all over it — bug will get squashed, fast. Low impact impact ... they tend to get backlogged, very rarely revisited. Definitely context dependent. For some start ups I've worked with, there's a move fast and who cares if it breaks mentality. At AWS, I was on a more critical, mature networking team and while speed was important, correctness (and lack of bugs) were valued much higher.
bedobi 5y ago
> Bob Martin saying "The solution to the software apocalypse is not more tools. The solution is better programming discipline." A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm). I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude. Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason https://softwareengineering.stackexchange.com/questions/320247/has-can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces/320262 https://softwareengineering.stackexchange.com/questions/3202... Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html This link and thread on hackernews is good too https://news.ycombinator.com/item?id=15440848 https://news.ycombinator.com/item?id=15440848 The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time). Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it. But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety. So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc. My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.
- mirekrusin 5y ago
  Linter or compiler should warn/error on unreachable code in this example, shouldn't it?
henning 5y ago
> When debugging a bug like that, there will be numerous wrong turns and dead ends, some of which can eat up weeks or months Warning: doing this at a startup will get you fired.
neilk 5y ago
I've run into issues of programming culture many times. I once joined a team that had tremendous amounts of copied code. I got a bit fed up with fixing the same issues across multiple files, so I created a tool to flag files with copied code in the codebase. This would have made me a hero at my previous company. The encouraged you to have a low programmer ego, and be very concerned with quality. Teams were often weirdly eager to try anything that could plausibly improve code. You could get promoted by making another hoop for programmers to jump through. But the new company had programmers with rockstar egos, and thought following rules were for losers. They valued how quickly they could get code from a programmer's editor into production, and organized everything around that metric. Introducing an automated code quality tool, that from their perspective, slowed things down and pointlessly blamed some people as lazy? That didn't make me popular. Programming culture is really an underrated aspect of the job. I'm not remotely as good as Dan, but I've also had a pretty varied career. I think many programmers, even if they job hop, spend their whole careers in the same sort of company. So they don't even know what else might be possible.
- fartcannon 5y ago
  "You could get promoted by making another hoop for programmers to jump through." That's right outta something Douglas Adams would think up.
  - barrenko 5y ago
    A junior designer joined my company. He was introduced to Slack and Basecamp. Working really fast, he got in trouble (and by that I mean about a 50 minutes brainwashing session) because he doesn't report "properly" the tasks he finishes and ticks off on Basecamp to his manager.
- emodendroket 5y ago
  For what it's worth, such a feature is baked into IntelliJ IDEA now. It will yell at you for repeating blocks of code.
  - 5y ago
makeitdouble 5y ago
> But if we look at quantifiable output, we can see that, even if processes and incentives are the first-line tools a company should reach for, culture also has a large impact. This split between incentive, process and culture doesn't make me comfortable. I think culture and processes emerge from incentives, and incentives are not just what the company signals (pay, perks) but also the effects of actions. For instance if reducing bugs brings company wide fame, money and makes everyone's work visibly better, people will spend more time on avoiding/fixing bugs, and a culture of quality will impregnate the teams. Process will be adjusted accordingly when they don't align with that culture. Someone moving to another job might bring that culture with them, but we know it will disappear if the incentives are completely different in their next job (if shipping 2 weeks faster and fixing bugs afterwards make a ton more sense, they'll adapt)
uyt 5y ago
> I do know of two cases of "fake programmers" (...) the person was able to sneak under the radar at Google for multiple years before someone realized that the person never actually wrote any code and tasks only got completed when they got someone else to do the task. The person who realized eventually scheduled a pair programming session, where they discovered that the person wasn't able to write a loop, didn't know the difference between = and ==, etc., despite being a "senior SWE" (L5/T5) at Google for years. I thought this only happens in tv shows. Was it more like Big Head from HBO Silicon Valley (the company forgot about the employee) or Frank Abagnale from Catch Me If You Can (conman who managed to fake his identity and credentials)?
- mettamage 5y ago
  How do you get past the interview stage if you don't know the difference between = and ==? Leetcode problems require you to know that.
  - smorgusofborg 5y ago
    Google seems to limit people to testing in a few similar abstracted assembly languages, but they buy out startups which might be using languages that discourage these simple loops, reassignments, etc that "every programmer uses". So quite possibly this was a perfectly good architect/programmer from a successful product who was turned into a C++ engineer on paper but never actually accepted the new role and only continued to architect.
- deleted 5y ago
  [deleted]
- redis_mlc 5y ago
  I know a bad programmer who got into Google using friends of his to do the interviews and a recommendation. His code was not usable in production, so we told him to forget the 2 weeks notice so we could get on with rewriting his stuff. It wasn't worth dealing with him. So it can be done.
- specialist 5y ago
ksec 5y ago
>I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That's a slap in the face to anyone who writes software for a living. ... It's a shame you have to do so much pre-screening to have the luxury of interviewing programmers who can actually program. It'd be funny if it wasn't so damn depressing Not sure if I should be happy or sad by this. Because I still dont think I can program at all. And I think part of the reason why FAANG ( or are they called MAMAA now ? ) are paying $200K for fresh grad and yet other there are part of US paying sub $100K. The range of qualities in terms of programmer is far too wide.
KingOfCoders 5y ago
What I'm amazed over and over again is the culture of children. Songs, rhymes, games are transmitted from kid to kid and stay the same over the years, without them being teached by parents. Although kids quite fast grow out of this the culture only moves very slowly.
tomerv 5y ago
I'm stuck on the first few paragraphs. It's clear that the author is heavily biased again anything-that-is-not-culture, and therefore gives really bad examples for non-cultural solutions. It's easier to convince everyone you're right when you give the worst possible alternative solutions. > Incentive: dock pay for people who are late There are much better incentive-based solutions. For example: - Managers reprimand employees who are frequently late. - Positive incentive for physical meetings: have a nice fruit bowl with just enough fruit so there are no leftovers for anyone who's late. > Process: make process for creating or executing on a work item so heavyweight that people stop doing simple work Better process-based solution: every employee has a "big" item that they work on, with planning weeks/months into the future, and syncing occasionally with their manager and/or peers.
- thrashh 5y ago
  I still find that there isn’t a true replacement for the right culture. Culture has wide ranging effects on how someone does everything, while a process only tackles one specific issue. You can’t make up enough processes to cover all cases as that results in overbearing bureaucracy. I’ll usually interview a company for at least a hour before I consider taking their offers seriously just to identify the type of culture that they have.
afarrell 5y ago
These three things also influence each other. Incentives act as a signal of the type of culture you want to incentivize. Process allows or blocks people from following that culture. Seeing leadership create processes and incentives that align with the stated values of a culture builds trust that those stated values are authentic.
sleepysysadmin 5y ago
So I was a sysadmin scripter(powershell/cmd/bash) then network admin, then infosec. Ive really blown up using python for all kinds of things last few years. I've built a whole honeypot -> threatfeed project. More recently I built a solarwinds ncm replacement(solarwinds got pwned) almost entirely in python. Long story short, it downloads config backups of network devices and then can programmatically report on security hardening guide rules. I work alone so my extent of 'culture' has been pycharm warnings. I imagine if another programmer saw my code they'd vomit so violently they'd have to buy new electronics. I try to do the right thing, but PEP 8: E501 line too long (125 > 120 characters) I'm not really caring too much about being 5 characters too long. I tend to comment my code well but there's certainly areas where there's nothing because the comments wont help much. Yet what ego do I have to get in the way? I know I'm not a programmer, I know there's tons of room for improvement. Its just... I don't know what I don't know. I feel this article speaks to me but I don't really have a mentor :( Edit/ just ran pylint against one of my projects. It fell over laughing.

205 points by ramimac 5y ago

> Culture: people enjoy building complex systems and/or building complex systems results in respect from peers and/or prestige Seems great for architecture astronauts. Maybe they'll stay long enough to eat their own crap. In the meantime, I'll keep in mind to stay away from such companies.

bhouser 5y ago
In case it didn’t occur to you: I think this was put forward as an example of culture producing negative outcomes.
- m0zg 5y ago
  Dan is actually referring to Google where "complexity" for a very long time was an explicit requirement for career progress to Staff level and beyond. I bet it's the same way even now, unofficially. For better or worse, engineers do not seem to sufficiently value simplicity, so people hated the rules, but played the game, producing insane rube goldberg like backends all over the place that you need whole teams of experienced SREs to run successfully. The fact that this is ridiculous was not at all lost on people either - memes on Memegen (an internal meme site) were pretty vicious. But, not a heck of a lot you can really do if you want those golden handcuffs to turn into platinum ones. I'd be remiss if I did not mention the silver lining in all this: Google's SRE team is very likely the most experienced in the world, and SREs are respected there. Stuff wouldn't run at all if this wasn't the case, and certainly not with five nines of reliability. Another bullshit requirement in the general case is "cross-team impact". No matter how valuable you are as an IC, you gotta get a bunch of other people involved so they write your peer feedback and endorse you for a promo. Sometimes this makes sense. Often it does not. And those people better be one or two levels above you, which is a problem in a remote office. There was a whole slew of antipatterns like that which might have made sense at some point in the past, but now are perceived as an immutable thing nobody can do anything about. So in a way, "culture" is not necessarily an _universal_ good, although at the time I was there the good outweighed the bad IMO. This cultural stuff is also why Agile by itself does not mean you'll be particularly "agile", nor is Agile required for high agility. As a manager I've found that if I can get people to care about things and give them autonomy, most of them will not require close supervision and will move faster than they'd otherwise. Some will require supervision, reminders, incentives, and all that, and those are best sequestered from the rest and grouped with folks with similar working styles and put to work on tasks that tolerate that kind of thing, or in clinical cases let go.
  - comlooogler 5y ago
    It is the same now, and officially so. One of the dimensions for perf/promo is complexity.
    - kevincox 5y ago
      IIRC it is still for "Software Engineers" but it has been replaced with Simplicity for "Site Reliability Engineers". Of course just changing the written rules doesn't change everything, and it creates an interesting friction.
    - m0zg 5y ago
      Sadness. There was a period of time when upper management knew this was a problem and tried to do something about that.
emodendroket 5y ago
I would hope nobody wants complexity for its own sake, but I do think there's something to be said for not shying away from a problem just because the only way to solve it is complex.

roca 5y ago

Incentivizing people to create complex systems sounds really scary to me. I guess there's an implied "where the complexity is absolutely necessary", but anything that approaches rewarding people for complexity sounds to me like one of the worst things you could for a software development organisation.

bawolff 5y ago

> Process: don't allow anyone who's late into the meeting Amount of people being late goes up once they realize they can skip stupid meetings simply by being "late"

bsder 5y ago
I have no problem with this, actually. If only people would actually take advantage of this. One the banes of good meetings are people who don't belong in your meeting but whose feelings will be hurt if they aren't invited.
- bopbeepboop 5y ago
  I quit a job because a manager made it insufferable by insisting he be invited to every developer meeting, then interrupting with useless tangents and requests people explain things to him.
ralmeida 5y ago
Fair enough, but in many cases some attendees attend only by inertia and would be better off declining instead anyway. Which is probably good overall if the meeting is indeed "stupid".
wence_ipon 5y ago
As someone whose calendar is often wall to wall, this is really stupid. The fact that I'm two minutes late because I'm a biological creature and need to piss occasionally doesn't mean I should be excluded from critical discussions.
- dexterdog 5y ago
  That's why all meeting should end at least 5 minutes before the hour or half hour.
  - analog31 5y ago
    They should have Bells, like school.

8note 5y ago

That process solution for getting people to meetings on time. I'd expect the meeting times to be changed to have more affordances for say, going to the bathroom between meetings, or the elevator being busy. A proper process solution says that the process is the problem, not the people using it

tharkun__ 5y ago
I see Google tried to 'address' this by having an option to make meetings go 5 minutes less than the "full" standard length. 30 minutes becomes 25, the hour meeting is 55 minutes. My experience, which matches exactly what I would expect from a technological solution to a people problem: Nobody cares, meetings still go 5 minutes too long instead of ending 5 minutes early. If at your company nobody keeps the time to the regularly scheduled time, nothing will change! It takes people actually keeping the time box of the meeting to change any of this. Be the guy that says "2 minutes left" 3 minutes before the end of the meeting. End your own meetings early by saying "running up on the time box, 2 minutes left" when it's 5 minutes to the end of the meeting and actually ending it. If nobody does that, nothing will change.

dan-robertson 5y ago

These examples at the start are great. I read the first thinking it was a bit silly and contrived but it worked super well to prepare for the second which was succinct but sounded familiar and then the third which sounded relevant to businesses but more positive and constructive than the first two.

itsmemattchung 5y ago

> debug a bug that takes more than a couple hours to debug because engineer time is too valuable to waste on bugs that take longer than that to debug, an attitude this person picked up from the first team they worked on Depends on where you live in the stack and the impact of the bug. Critical bug causing customer impact? You bet you are going to have tons of (senior) engineers jump all over it — bug will get squashed, fast. Low impact impact ... they tend to get backlogged, very rarely revisited. Definitely context dependent. For some start ups I've worked with, there's a move fast and who cares if it breaks mentality. At AWS, I was on a more critical, mature networking team and while speed was important, correctness (and lack of bugs) were valued much higher.

bedobi 5y ago

> Bob Martin saying "The solution to the software apocalypse is not more tools. The solution is better programming discipline." A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm). I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude. Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason https://softwareengineering.stackexchange.com/questions/320247/has-can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces/320262 https://softwareengineering.stackexchange.com/questions/3202... Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html This link and thread on hackernews is good too https://news.ycombinator.com/item?id=15440848 https://news.ycombinator.com/item?id=15440848 The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time). Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it. But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety. So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc. My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.

mirekrusin 5y ago
Linter or compiler should warn/error on unreachable code in this example, shouldn't it?

henning 5y ago

> When debugging a bug like that, there will be numerous wrong turns and dead ends, some of which can eat up weeks or months Warning: doing this at a startup will get you fired.

neilk 5y ago

I've run into issues of programming culture many times. I once joined a team that had tremendous amounts of copied code. I got a bit fed up with fixing the same issues across multiple files, so I created a tool to flag files with copied code in the codebase. This would have made me a hero at my previous company. The encouraged you to have a low programmer ego, and be very concerned with quality. Teams were often weirdly eager to try anything that could plausibly improve code. You could get promoted by making another hoop for programmers to jump through. But the new company had programmers with rockstar egos, and thought following rules were for losers. They valued how quickly they could get code from a programmer's editor into production, and organized everything around that metric. Introducing an automated code quality tool, that from their perspective, slowed things down and pointlessly blamed some people as lazy? That didn't make me popular. Programming culture is really an underrated aspect of the job. I'm not remotely as good as Dan, but I've also had a pretty varied career. I think many programmers, even if they job hop, spend their whole careers in the same sort of company. So they don't even know what else might be possible.

fartcannon 5y ago
"You could get promoted by making another hoop for programmers to jump through." That's right outta something Douglas Adams would think up.
- barrenko 5y ago
  A junior designer joined my company. He was introduced to Slack and Basecamp. Working really fast, he got in trouble (and by that I mean about a 50 minutes brainwashing session) because he doesn't report "properly" the tasks he finishes and ticks off on Basecamp to his manager.
emodendroket 5y ago
For what it's worth, such a feature is baked into IntelliJ IDEA now. It will yell at you for repeating blocks of code.
- 5y ago

makeitdouble 5y ago

> But if we look at quantifiable output, we can see that, even if processes and incentives are the first-line tools a company should reach for, culture also has a large impact. This split between incentive, process and culture doesn't make me comfortable. I think culture and processes emerge from incentives, and incentives are not just what the company signals (pay, perks) but also the effects of actions. For instance if reducing bugs brings company wide fame, money and makes everyone's work visibly better, people will spend more time on avoiding/fixing bugs, and a culture of quality will impregnate the teams. Process will be adjusted accordingly when they don't align with that culture. Someone moving to another job might bring that culture with them, but we know it will disappear if the incentives are completely different in their next job (if shipping 2 weeks faster and fixing bugs afterwards make a ton more sense, they'll adapt)

uyt 5y ago

> I do know of two cases of "fake programmers" (...) the person was able to sneak under the radar at Google for multiple years before someone realized that the person never actually wrote any code and tasks only got completed when they got someone else to do the task. The person who realized eventually scheduled a pair programming session, where they discovered that the person wasn't able to write a loop, didn't know the difference between = and ==, etc., despite being a "senior SWE" (L5/T5) at Google for years. I thought this only happens in tv shows. Was it more like Big Head from HBO Silicon Valley (the company forgot about the employee) or Frank Abagnale from Catch Me If You Can (conman who managed to fake his identity and credentials)?

mettamage 5y ago
How do you get past the interview stage if you don't know the difference between = and ==? Leetcode problems require you to know that.
- smorgusofborg 5y ago
  Google seems to limit people to testing in a few similar abstracted assembly languages, but they buy out startups which might be using languages that discourage these simple loops, reassignments, etc that "every programmer uses". So quite possibly this was a perfectly good architect/programmer from a successful product who was turned into a C++ engineer on paper but never actually accepted the new role and only continued to architect.
deleted 5y ago
[deleted]
redis_mlc 5y ago
I know a bad programmer who got into Google using friends of his to do the interviews and a recommendation. His code was not usable in production, so we told him to forget the 2 weeks notice so we could get on with rewriting his stuff. It wasn't worth dealing with him. So it can be done.
specialist 5y ago

ksec 5y ago

>I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That's a slap in the face to anyone who writes software for a living. ... It's a shame you have to do so much pre-screening to have the luxury of interviewing programmers who can actually program. It'd be funny if it wasn't so damn depressing Not sure if I should be happy or sad by this. Because I still dont think I can program at all. And I think part of the reason why FAANG ( or are they called MAMAA now ? ) are paying $200K for fresh grad and yet other there are part of US paying sub $100K. The range of qualities in terms of programmer is far too wide.

KingOfCoders 5y ago

What I'm amazed over and over again is the culture of children. Songs, rhymes, games are transmitted from kid to kid and stay the same over the years, without them being teached by parents. Although kids quite fast grow out of this the culture only moves very slowly.

tomerv 5y ago

I'm stuck on the first few paragraphs. It's clear that the author is heavily biased again anything-that-is-not-culture, and therefore gives really bad examples for non-cultural solutions. It's easier to convince everyone you're right when you give the worst possible alternative solutions. > Incentive: dock pay for people who are late There are much better incentive-based solutions. For example: - Managers reprimand employees who are frequently late. - Positive incentive for physical meetings: have a nice fruit bowl with just enough fruit so there are no leftovers for anyone who's late. > Process: make process for creating or executing on a work item so heavyweight that people stop doing simple work Better process-based solution: every employee has a "big" item that they work on, with planning weeks/months into the future, and syncing occasionally with their manager and/or peers.

thrashh 5y ago
I still find that there isn’t a true replacement for the right culture. Culture has wide ranging effects on how someone does everything, while a process only tackles one specific issue. You can’t make up enough processes to cover all cases as that results in overbearing bureaucracy. I’ll usually interview a company for at least a hour before I consider taking their offers seriously just to identify the type of culture that they have.

afarrell 5y ago

These three things also influence each other. Incentives act as a signal of the type of culture you want to incentivize. Process allows or blocks people from following that culture. Seeing leadership create processes and incentives that align with the stated values of a culture builds trust that those stated values are authentic.

sleepysysadmin 5y ago

So I was a sysadmin scripter(powershell/cmd/bash) then network admin, then infosec. Ive really blown up using python for all kinds of things last few years. I've built a whole honeypot -> threatfeed project. More recently I built a solarwinds ncm replacement(solarwinds got pwned) almost entirely in python. Long story short, it downloads config backups of network devices and then can programmatically report on security hardening guide rules. I work alone so my extent of 'culture' has been pycharm warnings. I imagine if another programmer saw my code they'd vomit so violently they'd have to buy new electronics. I try to do the right thing, but PEP 8: E501 line too long (125 > 120 characters) I'm not really caring too much about being 5 characters too long. I tend to comment my code well but there's certainly areas where there's nothing because the comments wont help much. Yet what ego do I have to get in the way? I know I'm not a programmer, I know there's tons of room for improvement. Its just... I don't know what I don't know. I feel this article speaks to me but I don't really have a mentor :( Edit/ just ran pylint against one of my projects. It fell over laughing.