Hacker News Reader

Your comment reminds me of Jeff Goldblum’s character in the movie The Fly, when the reporter asks him how he could have built the teleportation system by himself and he says:

“I don’t work alone. There’s a lot of stuff in here that I don’t even understand. I’m really a systems management guy, I farm bits and pieces out to people who are much more brilliant than I am. But none of them really knows what the project is. I say build me a laser this, or a molecular analyzer that - and they do, I just stick them all together.”

I recently had to build an e-commerce portal for our customers to be able to order 3D printed parts on-demand. Did I write my own algorithms for rendering 3MF files and calculating the volume of a mesh? Nope, I just used three.js and a mesh volume algorithm I found on Stack Overflow and problem solved.

Anyone who’s used an import statement can relate to this.

Eh; I encountered one of these "Google" programmers before. It was exactly as the author described. Fortunately, they did something unrelated that gave us no choice but to fire them.

Most of the skills you mention (business requirements, task management, spelunking legacy crap, etc) only really matter in large organizations, where human coordination costs and tech debt management dwarf actual development costs.

In a well-run small org, ICs can get by without them by having an occasional coffee/lunch/beer with the CEO/CTO/Sales head.

I've worked in both kinds of companies and plenty inbetween and I have to disagree. In small companies having a good handle on the business requirements is even more important, and it's frankly even more the case that it's not a simple matter of "how" you program but "what."

In a small company a frankly larger percentage of company revenue can be wasted through crappy project and product management. Coding it poorly is often the least concern at places like this. It's getting the right thing to market.

Come on man, junior or mid level engineers are suposed to do well defined tasks, or projects. It is part of the Team Lead, Lead/Staff engineers to reduce the business requirements to a relatively well defined project.

That's how most mid level, and large companies work. You are not hiring an engineer with 2yoe to 'coordinate business values', unless you work at some scrappy startup.

The original article has a good point: Young engineers are so used to google for everything, that they often don't understand the code, or framework they are working with.

Back in the day (prior to StackOverflow), we called them "Framework, Glue and Paste Engineers". Basically people that used frameworks without understanding what they did. It was fine for basic stuff, until the point you crash servers because you have no clue what did Hibernate do under the hood with those queries.

Anyway.... the article is clearly aimed at more junior hires.

> they did something unrelated that gave us no choice but to fire them

Out of curiosity(from lack of experience working for a company), what are some things that lead to this situation?

I remember this personality being common among programmers from eastern Europe. By no means universal. If you work with these types you just have to have a thick skin. I think they generally mean well.

Maybe the internet is creating a situation where the workplace is no longer populated by a Dickensian cast of oddballs, but I feel like super polite workspaces where nobody ever calls people out and everyone is given pats on the back lack something as well. And under the surface is often disdain that is never voiced, just acted upon.

At least in the US there are too many companies paying too well to waste your life working with assholes on your team.

> I remember this personality being common among programmers from eastern Europe

This is HN and I do not want to make a personal attack or anything against you. But this comment is clearly discriminatory and, frankly, what ever a light version of "racism" is. Please stop generalising millions of people based on some anecdote and spread it online. Eastern Europeans are already marginalized in the Western software world, and English is a non-native language to them. They are as diverse as you and me

As someone from Eastern Europe I can relate the comment of @projektfu to myself and I do not think the comment is derogatory. There is some work ethic in Warsaw pact countries that is totally absent elsewhere. A topic for a PhD in anthropology, for sure.

OTOH, Dutch are notoriously blunt as well.

The Dutch, the Israelis and everyone east and North of Germany. It's pretty refreshing in some respects, but the friction between these blunter and less blunt cultures can be massive.

The funny thing with Dutch is that Dutch speakers from Flanders are as much snowflake as everyone else.You really have to have this North Hollander protestant past to stand out.

You should read more about what racism is before you go around accusing other people. Or perhaps better, stop reading so much about racism that it makes you confuse a personality trait with a race. Such a personality is common among young white left men, please stop spreading that online. It does not contribute to diversity, but only divides.

You're right it's not racism, but it's cultural stereotyping and it's still a pretty shitty broad brush to paint people with.

Why? Nobody said one is better than the other. Are you going to pretend all cultures are the same? if you've ever traveled or lived abroad, you will quickly come to the conclusion that there are major differences in how (say) Eastern Europeans approach communication vs people from the US. And that's okay. Nobody needs to be offended.

I live in Eastern Europe (Bulgaria). I have lived all my life in Bulgaria. OP has it spot on. Stop being "offended" on my behalf. I would much rather be stereotyped, offended, called names, discriminated against, etc. rather than have one of your ilk try to come to my defence.

This extreme response seems to make no sense either :)

As another Eastern European programmer, I would like to bluntly disagree with you as well.

As a developer from Eastern Europe:

* it is true we are more blunt than a lot of our Western colleagues

* blunt does not mean impolite -- I always try to say what I mean with plenty of layers of courtesy, but I do not mince what I mean

* the guy in the article seems like an asshole by Eastern European standards too (mentioning "my charisma" is pretty egoistical no matter how you spin it)

> Eastern Europeans are already marginalized in the Western software world

Not completely wrong but I'd say the software industry is the place I have felt the least marginalized. I left Eastern Europe and finding a job in the software industry was very painless for me, while other places would wish for perfect command of the local language, or discriminated against me almost explicitly. Which leads me to your next point..

> English is a non-native language to them

While true, it is rather annoying to have people hold this over your head when you speak and think in English for decades. I'm more well-read than half my native English colleagues who haven't picked up a literature book since high school, yet being "non-native" means that I constantly have people doubting my ability to speak English. At least I no longer have to hand in TOEFL exams to prove I can speak the language that I think in 24/7, including when I'm talking with my workmates, girlfriend, showering, taking a shit etc..

Culture exists.

I appreciate your input :)

Reminds me once trying to get an answer to a noob question about some Cisco equipment. Want to talk toxic culture, Cisco networking services, totally toxic. Couple of forums where someone asked the same question just received smug non answers in response.

Finally found a Russian lang forum where it seemed someone asked and a long response. I used to google translate. Half the response was the author insulting the guys mother followed by a detailed profanity laden answer.

I'm not seeing a good reason to assume these people were any better at business requirements etc - if only because Google is going to be even less help with those.

We've had this before on HN. Student and work culture is changing from "Work it out for yourself because you're a skilled professional who understands how to solve real problems" to "Copy it from someone else without understanding anything about it because that's what you did to get your expensive degree."

It's not so much Google programming as Lego programming. And it's a terrible way to approach any kind of engineering, at any level.

Of course it's fine to import good existing solutions if you know what you're doing with them. But Lego programming is not that.

The original author is Ivan Belokamentsev (as mentioned) and judging from his Habr profile you won't meet him unless you are willing to move to Russia and learn 1C (https://en.wikipedia.org/wiki/1C:Enterprise)

Ah, oops, I skimmed the header portion and missed that part, thanks.

His experience is limited to 1C programming, which occupies similar business niches as SAP. 1C ecosystem is utterly different from HN's.

Leaving them in the room to complete the tasks was an early red flag here. If you have no insight into how people think about and complete tasks then you are testing the product of their time, not their approach to problem solving. You then shouldn’t be surprised by the lack of what you didn’t test for after the fact.

Honestly, having done everything you listed above over couple decades: no, not really. Developing code is still the hardest part. It's a lot harder to get a good programmer with consistent output you can rely on your estimates than an ass to warm a seat in Big Picture meetings.

I am in the opposite camp. I want to work for the author of the article because he gets it and he has humility, a trait that top level commenter (who informs us unironically in his profile that he likes grapes and other plants) needs some work on.

Also the article is translated from Russian(?) into English, which I’m sure is responsible for some of the odd diction.

Indeed. The author just wrote yelling. Given the Russian culture I suspect he was yelling in chats about the situation, not blaming a particular person or team. Something like “Why the hell have we stuck?” perhaps even with f-words. Boss expressing himself in such way is rather common in Russia. If such yelling is followed by reasonable suggestions, it is not even perceived as offensive, but as the way to emphasize the gravity of the situation.

Sure, re-reading it I do pick up that the author was perhaps attempting humour and self-criticism throughout. But there's still boatloads of red flags starting with the interview process (toss them in a room and get them to write some code as the measurer of the value of the candidate) and ending with the whole concept of "re-interviewing" people.

It doesn't matter how humorous or humble the author might be, these alone worry me. Y'know, me, that arrogant guy who likes grapes.

In any case it's clear the original author does not live in a tech job market anything like North America, where a request to "re-interview" someone would be met with a confused stare followed by a middle finger.

How is liking grapes a fault in their humility?

Right? I've seen some weird criticisms, but "lol you said you like grapes and plants" takes the cake.

Trolls will keep trolling(you).

This is only true if you're a beta bucks provider doing CRUD to support a family. There are plenty of real programmers out there working on their own projects and the hard part in these WORTHWHILE projects is certainly the programming :)

I have my own personal projects and on them, yes, the programming is the hardest part.

Leading a team or joining a new one? It's translating what the company needs into the set of instructions. Ambiguity in that process leads to stalled juniors, even if they're excellent coders. I've been there, both as the frustrated demoralized junior and, later in my career, as the team lead trying to make that process work.

Yes, I'd be concerned if someone literally cannot write compilable code in the programming language you're working in. But usually if someone makes it far enough to be employed there's something else going on if they're producing serious garbage. Skill, attitude, motivation, team morale, or bad instructions and bad leadership. Honestly, my experience in seeing teams dysfunction is that it's best to start from the end of that list and move backwards.

I am so glad this is the top comment. The author of this post sounds like a horrible person to work for.

Also, we need to deliver a swift kick in the nuts to this unlimited growth philosophy. People under you NEED to plateau, that is their comfortable level of productivity. You don't force growth, that is something that comes naturally and at an unpredictable pace.

The issue isn't that they plateaued, the issue is WHERE they plateaued. If you get most of your code output by googling, you're going to plateau pretty early.

If you're also getting thrown into dealing with COVID lockdowns and WFH-related organizational overhauls, and then get yanked back into the office months after that, that's going to do a number on your productivity, too.

If software engineering is not the 'hard part', why are dev salaries so high?

Because the "engineering" part is literally all that other stuff which is actually quite hard. Just like a civil engineer doesn't pour concrete for a living, we don't write sort or string search algorithms for a living, we build solutions that solve company problems. Usually using someone else's well-built sort or search algorithm. When I need to write the latter, I reach for my Knuth books.

That said, I still bridle at the term "software engineer"; I mostly accord with Alan Kay's quote "Software engineering hasn't happened yet."

Everything else the OP listed is project and product management. You can get devs to project manage, you can't get project managers to write code.

I am the OP, and I don't think I've ever had a project or product manager who gave me sufficient detail such that all I had to do was walk away and "write code."

Problem solving skills required and a bunch of questions. What really do you need, how important is each part of it, and who are the other people I need to talk to help make this happen? Being able to ask those questions and produce code from the answers is what we get paid the big bucks for.

At least for now.

You're the parent commenter not the OP. The commenter was referring to the OP (Original Post) i.e. the posted article.

Wow, well said. It is so true that effective programming really requires a lot more support, especially around the product/business/project side. The smaller clear the chunks of work, probably the easier it is to reason about and complete.