Unless you're using a functional programming language that does not support iteration. (and even if it does support it, it's typically preferred to use tail recursion)
While others are by GOs possessed,
And WHILE-DO, CASE, and all the rest,
The LISPing hackers will prefer
With COND their programs to invest
And let their functions all recur
When searching trees in maddened quest.
The bigger issue is that they're essentially entirely incorrect. "Recurse" is both in common use and well understood. I'd even argue that it's more correct than "recur", since it's unambiguously about recursion.
This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...
I'm currently working on a mssql shop, and on aws it's more than twice the price vs postgres or aurora. I don't see how you can justify the price difference
"Orthodox C++" looks more like writing C-code and keeping the C programming style. Most of the points are really questionable.
- "In general case code should be readable to anyone who is familiar with C language". Why should it? C++ is a different language than C. I speak german, but I cannot read e.g. French unless I learned it even though they are related.
- "Don't use exceptions". Why? There is no performance penalty in the non-except case, and the exception case should be rare because it is exceptional. I can see arguments for real-time systems, and for embedded systems were code size matters. The alternative is C-style return codes and output parameters. Exceptions are better in that case because you cannot just go on after an error condition, and functions with output parameters are harder to reason about because they loose referential transparancy. Of course, in modern C++ one could use optional or expected types.
- "Don't use RTTI". I never needed RTTI in my professional life.
- "Don't use C++ runtime wrapper for C runtime includes". C++ wrappers have some benefits over the C headers. They put everything in namespace std, so you don't need to use stupid prefixes to prevent name clases, and they define overloads for some of the C functions, e.g. std::abs(int) and std::abs(long) instead of abs(int) and labs(long).
- "Don't use stream, use printf style functions instead". If this means to use a type-safe printf variant I could agree to some point, although custom operator(<<|>>) for custom types are sometimes nice. If it means to use C printf etc I would strongly object.
- "Don't use anything from STL that allocates memory, unless you don't care about memory management". You can use allocators to use e.g. pre-allocated storage. The STL also contains more than containers, why would you not use e.g. the algorithms and implement them yourself?
I always interview for "culture fit". In my experience, that's almost always the bottleneck, and the technical part is rarely a problem. Learning a new skill is not an earth-shattering problem if you have a good attitude towards work, and good interpersonal skills are a must in teams
I've been looking for another word for "someone who is interested in the same software engineering and organization practices as the rest of the team" without using culture fit.
I don't care what TV shows they're watching or the color of their skin, but I do care that they don't grate against testing a peer's ticket instead of thinking it's below them. I care that they are helpful as a human quality. I care that they are interested on working on a team that's highly collaborative.
There are places where I'm not a great cultural fit. If the team's culture is to take a problem, go off for months, and solve it, it's probably not for me, but I know people who would be overjoyed in that case. I know people who'd like nothing more to get a spec and deliver rather than gathering and implementing requirements based on conversations within the organization.
In some sense, that's people like me, but I was in turn hired because I fit those criteria. People who fit those criteria seem to be happy with the engineering portion of the job, and people who don't fit that criteria tend to be frustrated.
I use the word "cultural fit" but I'm not sure if there's a better term.
Some people have a bigger need to find a good fit on this, but many of the choices are philosophical in nature and having constant battles over why so/don't we do X is not productive. (Having occasional discussions can be productive, especially if there are clear deficiencies in the current flow).
As an interviewer, I appreciate when candidates ask about our process, regardless of if they love or detest what we do, I know they're asking important questions. As a candidate who can afford to be choosy, I would ask this of interviewers, as I know from experience I'm not going to be happy if I am fighting with the process all the time.
Can you not just say "someone who is interested in the same software engineering and organization practices as the rest of the team"?
I get that it's more than two words, but it clearly expresses what you're trying to say and makes it clear you don't mean what so many others mean when they say "culture fit"; same schools, hobbies, affluence, political attitude, and so on.
That said, seems like you might benefit more from people interested in different practices; people who can bring something new to the team, rather than more of the same.
There's a difference between someone who is looking through new ideas and suggesting that we try experiments to improve our quality, time to delivery, or the other things our team finds important, and someone who is irritated at the thought of writing unit tests or that they have to test a peer's code.
someone who is looking through new ideas and suggesting that we try experiments to improve our quality, time to delivery, or the other things our team finds important
So someone who is interested in different software engineering and organization practices? Not the same software engineering and organization practices as the rest of the team?
It sounds like you don't want a culture fit so much as you have a culture in mind that doesn't fit, and you don't want that one. Different culture fine, except from a particular range of damaging cultures.
I would suggest that the very fact this thread (and others nearby) exist indicate that "culture fit" really isn't a good term, given how much extra definition is required.
Neither of those are even close to better. Basically the same but with more letters and muddy the waters.
The only way to improve the concept, IMO, is to find the definition of the real thing you are looking for. I think the goal is exponential outcome? That's what business owners are looking for with any hire. Fit is silly, it all seems like a puzzle, but it's an ecology. You want a catalyst that challenges and unifies or someone that strengthens the existing base.
As mentioned above, the best way to describe is that people who want a culture like http://programming-motherfucker.com/ advocates for is the wrong fit for us.
And that's the problem with fit questions - it's much easier to say what is not us rather than what is us. I like the ecology metaphor, though. Organizations as ecologies...
You just failed the "being civil" part of the interview. I think I'll let the GP judge whether those are better. At least I'm trying to help instead of just slinging stones at others' attempts.
> Exponential outcome maybe?
Seriously? You complain about "more letters" and muddying the waters then you vomit up that monstrosity?
I am really sorry you read that that way. I was not saying your contribution wasn't useful to the dialog. I was just saying that I think the category of "fit" doesn't need a different term at the front but more a rethink. I was not saying "Exponential Outcome" was a better set of words, but just my first blush at what I think the desired thing in a hire is that could be used to define new terms. I've changed my post to reflect that.
Again, sorry for making you feel like I was shitting on your contribution.
> I think the category of "fit" doesn't need a different term at the front but more a rethink.
That didn't seem to be what $ancestor was asking for. It sounded like s/he was wishing for a slightly different phrase for a slightly different concept, vs. what "culture fit" usually means. Your "rethink" was not that. It was a complete shift from strategy to outcome. Is that help, or appropriation? Not for me to decide, but perhaps something to think about. It's a mistake we engineers often make, and I'm hardly innocent myself.
I was recently hired for a job at a high level position that I'm really excited about. While hiring me the CEO said "You are a bit outside of our normal culture, but we have talked and think that's an asset". I had to question that.
I'm a college dropout with 18 years of consulting and startup experience and they are all highly skilled academics. He even recognized that it was a backhanded compliment. The "culture fit" term has always bugged me, but it really came clear to me in this meeting. It's a useful cypher for exclusion on class and world view. I'm pretty sure that's not immoral or wrong, but I do think the concept is damaging to organizations that want an exceptional outcome. Turns out business is risky and basically runs on what can be predictable.
Working with people you like is really important and at high level jobs, there are few people that can transcend from outside orbits. The only reason I can involves a lot of hard fought failures and an ability to explain myself in documentation and method. A large amount of successful engineers have had a protected arc of experience that makes the unfamiliar grating and closes off dynamism that could come from people that don't whip ideas from the same pocket they pull from. Being an engineer seems to also be magnetically opposed to the nuances of human resources too. A lifetime of meditation on failure can sometimes nerf the poetry available in human experience.
I have no solution to it broadly. Stoked on the new job, it looks like I'll be in charge of hiring too. I have a good track record with it in my own org, but the stakes here are bigger. If I get proof of my method I'll report back, if I fuck it up I'll probably be fired for bad culture fit.
> Isn't culture fit just another word for "people like me"?
My ex came to me in a rage the other day because the large bank she works for had produced a promotional video for HR purposes talking about success that was presented before a presentation on diversity, and where every single person interviewed from the bank was a white, blond male, while black people were only presented when cutting to news footage (e.g. of Obama etc.) - they apparently couldn't, or didn't want to, find a single black person or asian person in a workforce of tens of thousands that they could use...
The same bank created a promotional ad to hire more women in an Asian country last year where of 10 women, 9 were white blondes and only one was actually Asian.
And then they wonder why they don't get more black or asian people applying for jobs.
To top it up, they strongly prefer people from a small pool of schools that are expensive and strongly favor children of alumni to the extent that their preferred hiring pool already is very heavily skewed towards white upper class men.
Their "diversity team" works within that constraint: To have to try to capture the very small black and asian contingent that fits hiring criteria and a culture that is so strongly predisposed to them that even if they hired everyone that met the criteria and were willing, they'd not get close to achieving diversity in any meaningful sense.
It's a real problem that many places want things like "culture fit" without actually thinking about how they actually ue that.
Often even while putting together committees to try to solve specific hiring problems that can't do their job because the "culture" is holy and questioning whether or not it is being so narrowly construed that it causes extreme monoculture is often not acceptable...
(to be clear I'm not suggesting the person you replied to or others here are doing what the bank in question is doing - I just wanted to give an extreme example of what "culture fit" can lead to, even without it necessarily being the intent)
> Isn't culture fit just another word for "people like me"
More like: people who aren't going to grate on me, which is very different and encompasses a much larger set of people.
The "culture fit" strategy can no doubt be abused, but it's also wrong not to recognize that a technically brilliant hire
can be terrible for the company if there are communication problems or personality conflicts.
This type of selection (“people who don’t grate me”) often favors people that are similar to us. Project Implicit[1] at Harvard has done interesting work highlighting our difficulty to make “objective” judgements (esp. about other people that are different from ourselves), and that we go to great lengths justifying our biased decisions not just to others but to ourselves. Hence “implicit” biases.
Is that really so bad? Obviously when extended to race/sexual-orientation/etc it is, but isn't it legitimate to some extent to want to surround yourself with people who share your values?
This is precisely the issue that the social sciences often miss because it's an ethical, not scientific, question.
It is pleasant to live in echo chamber and that is exactly what you would build there. And the result is place where people don't talk about issues and don't solve problems if doing so would go against groupthink. And just like in any echo chamber, consensus will more more toward extreme and people will simultaneously become less and less capable of handling different opinions.
>This is precisely the issue that the social sciences often miss because it's an ethical, not scientific, question.
You're completely missing the point - if it doesn't get results, they're not going to do it regardless of whether it's morally acceptable or not. Businesses care about results.
With all due respect (truly!), you are missing the point.
The point is: scientific arguments fail to convince because the issue escapes the scientific domain. The question is not "do we naturally tend to do X, Y or Z", but rather "at what point and to what extent are we ethically obligated to seek out people different from ourselves?"
>Isn't culture fit just another word for "people like me"?
I've noticed that an emphasis on "culture fit" does tend to correlate with an ethnically & culturally homogenous workplace.
I think most of the candidates I've interviewed and recommended for hire that have been rejected for a vague/no reason have all been foreign.
IMO hiring for culture fit is fine provided you're willing to be very specific and state directly to the candidate's face what aspect of your desired 'culture fit' that they failed.
Are you suggesting that "cultural fit" and "interpersonal skills" are so well defined and bounded that they are completely distinct, and definitely do not overlap?
I remember hearing about a study that success in engineering graduate school is better predicted by the GRE writing scores than by the math scores. So could general communication ability be more important than engineering ability when it comes to job performance (on average, across all people & jobs)? Is it possible that both "cultural fit" and "interpersonal skills" are both trying to get at whether someone is a good communicator who emphasizes getting along with the people around them?
> Learning a new skill is not an earth-shattering problem...
Depends on the problem. If you're cranking out brochure websites from a set of templates, you have a pretty accessible role to fill.
But I have many colleagues who make mistakes (even when people object clearly), dig a hole for themselves, double down on the mistake, and the either back their way into job security with their mess or end up moving on once the chickens come home to roost. Some of the time, I can even see their eyes glaze over as I try to get them to think a few more moves ahead in their plan.
Now, organizations should have safe roles for journeyman engineers who crank out and maintain code as directed, but most organizations expect all senior engineers to be part time system design experts, which I don't think everyone has the knack for. Likewise, not everyone is a great communicator and strong enough technically to be accurate in their communication.
> But I have many colleagues who make mistakes [...] dig a hole for themselves, double down on the mistake, and the either back their way into job security with their mess or end up moving on once the chickens come home to roost.
A skilled practice of behavioral interviewing can, I think, mostly screen out such candidates. People who have a habit of "doubling down on their mistakes" will find it hard to wiggle around pointed behavioral questions which require the candidate to describe real experiences and answer follow-up questions.
The problem is that most organizations are terrible, TERRIBLE at evaluating candidates. They forget that interviewing candidates is a skill in itself that needs to be developed and needs to be consistent across the organization.
Moreover, these same organizations fail to "close the feedback loop" when it comes to evaluating employee performance. The "annual review" data can be put to good use by informing hiring decisions. Instead annual reviews are just an irritating burden used for the purpose of carving up the raise/bonus pie. It is basic engineering... evaluate your outputs (employees), then use that data to adapt to your inputs (candidates). But virtually no one does it, because its all tied up in HR-bullshit instead.
>But I have many colleagues who make mistakes (even when people object clearly), dig a hole for themselves, double down on the mistake, and the either back their way into job security with their mess or end up moving on once the chickens come home to roost.
Your making the parent's point for him. This is a behavioral problem. Hence, screening for culture fit.
No. These people are generally open to suggestions that they grok. They just can't, at least sometimes, comprehend more indirect or abstract problems (like CAP theorem implications that influence the design of SQL tables and business keys). They write code that meets requirements in the short run but get bogged down in a local maximum that can't be improved upon without an expensive rewrite.
That prompts two questions for me if you don't mind sharing.
(a) How do you define and assess "culture fit", and why?
(b) How do you know the things you're optimising for are actually good proxies for productivity?
Appreciate these aren't questions with simple answers (or maybe even answers at all), but hiring/assessment process is my current field and I'm always curious where peoples thinking is at.
That’s a fancy way of saying “we hire people we like”.
It’s an approach that isn’t perfect but is good enough for many roles. We pick spouses based on that approach and it works out pretty well for most people.
You are correct, "culture fit" is not a good descriptor of what I meant.
We hire people we believe we will be able to work with. It's not a popularity contest, we evaluate problem solving, analytical thinking and communication skills, such as the ability to explain complex topics in easy terms.
I'll give you an example, usually we are interviewing people straight out of the university, but this can be applied to any candidate.
I'll start by asking the candidate to talk about his master's project. As he talks about it, I'll guide the conversation towards these topics :
-What was the problem
-How was it defined?
-How did you tackle it?
-Explain your solution
-support your decisions
-Was there a cost/benefit analysis?
-How was the problem decomposed?
This will give me an initial picture of the candidate's ability to address a problem, and is far more important to me than wether he knows "the number after F in hexadecimal" or some other nonsense.
This isn't screening for 'culture fit' though and I'd sincerely recommend avoiding referring to it as that. You're screening for strong communication skills and that's absolutely fine (and highly recommended).
Interviewing for culture fit (as you've seen in the responses to your comment) has an extremely negative stigma attached to it for good reason.
I strongly agree with this. “Culture fit” is one of those concepts that often disadvantages “others”. This is something we may not be able to avoid without putting in place safeguards (concert musicians were predominantly male until blind auditions were used - and it turned out that female musicians play just as well or better).
As I mention above this is often not a result of bad intentions, but of implicit biases that have an effect on our judgements even if we are fully aware of them and explicitly try to avoid them.
About half of all marriages fail. All the intimate relationships people have prior to marriage also don't last. So people we like has a fairly high failure rate for intimate relationships.
Having said that, it doesn't necessarily mean it was all a complete waste.
Most people don't stay in their first job, so there's that.
The two are pretty tightly linked. If you have an underemployed or unemployed couple without a support network, you pretty much have to get divorced to get social services.
I don't walk into any job interview situation expecting 30 years of bliss -- that's generally not a reality. If you stick around for 3 years that's probably a decent employment relationship depending on industry.
Many marriages, including those that ultimately fail, work pretty well for a long time. I'm not that old, and I've been married for 13 years. Is that a win?
Also, the average marriage is around 8 years, but the median is close to 40 iirc. People who get divorced trend to have issues like being young, poor, previously divorced, criminal issues or substance abuse problems. Divorce rates for couples at least 25 without those risk factors are dramatically lower -- implying that people with fewer signs of bad judgement display better judgement in picking a spouse and maintaining a relationship.
As someone who indulges in more than his fare share of young/poor/previously separated/criminal issues/substance abuse problems... I attempted to capture that in my somewhat more terse "Having said that, it doesn't necessarily mean it was all a complete waste." Thanking for expanding on that where I was laconic.
I may be in the minority, but I find the 50% unit test coverage not useful, and sometimes harmful. Caveat emptor - depends a lot on the project, and how often you are changing the code and/or the complexity of said code.
Join the club, then. My view is there is a borderline unhealthy obsession with unit testing to the point that the actual product code takes a back seat (in quality and functionality) just so that some usually arbitrary measure of "testable" applies to it.
> lack of coverage isn't necessarily an indicator of lacking quality.
"lack of coverage" mostly means "untested code".
My experience is that it's very hard to keep untested code to a high quality level.
Any modification that isn't directly justified by a customer feature or a bug fix is frowned upon, because it's hard to tell if it breaks anything ; which means you pile up new features, but you can never modify their design so they fit better together.
When the philosophy is "now it works, let's never touch this module again!", code quality goes down to the toilet.
It is less a question of whether the percentage is correct than whether the tests are useful. I've seen plenty of useless tests (testing getters and setters in Java) that assert nothing related to the codes functionality but exist solely to boost coverage. Which is why asserting a strict coverage percentage is dangerous.
This. Slavish fetishization of a specific code coverage target is indicative of an underlying problem, IMO and that problem is far greater than one having relatively low code coverage.
It is far better IMO to go in with an understanding of where your potential hot spots are than simply adding a test to everything. Sure, in an ideal world we'd have 100% coverage of everything but this field is about tradeoffs and sometimes writing tests simply isn't worth the time it takes to have written them in the long run.
In my experience it's too high. I see a lot of unit test code that doesn't do anything except add complexity. But again, I guess this will depend on the nature of the project
