Managers dont have the time to figure out if someone did something well or poorly. The code works and so they move on. Certain people leave a trail of bad code with nice looking syntax. Working directly with them, it will be obvious, but otherwise forget it, you will never figure it out. All it takes is them speaking well in meetings/good at project planning/BSing some design.

The result of their bad code is future changes take 2x-3x as long. But no one can tell if those timelines are just what they are, or that there is a problem with the existing code.

I think there is a difference between bad and good places. I have worked in bad places where things worked exactly as you described. Fortunately times have changed, and places I work now care about quality. Most of the time managers used to be engineers and they either know and care about it, or they care and rely on input from other engineers to understand what is going on under the hood.

Eh I've seen this even at FAANGs.

The thing is, the syntax/design patterns in the code can look clean. But that doesnt mean the abstraction/interface is the right one

Every formalization of a workflow is susceptible to this.

I recall how when Git started getting widespread adoption, a popular blogpost theme was discussion of cleaning up your commits...which is the kind of thing you can do if you're writing in small increments. But code that "moves mountains" in the architecture, as is often the case in a greenfield project where there's a lot of learning being done, tends to have dirty rip-off-the-bandage moments. If you clean up those kinds of commits, it's not really beneficial to future code archeology. But if you're clocking minimal effort and maximum CYA, it suddenly becomes hugely important to dot the i's and cross the t's, because that looks more professional than a commit log where you iterate on it a bunch and your log is like "maybe it's fixed now?"

Agree, with the caveat that the more often these BS conversations occur in a group setting, the more likely a BS-er is to be caught by his peers.

It doesn't matter what the peers think, if the BS-er is manipulating the manager well.

My thesis is that in software it takes an expert to identify another expert, and outsiders struggle with being able to tell who's full of shit. You end up with pseudo-metrics like lines of code and random inspections of the last bit of code you wrote (e.g. muskian Twitter).

An experienced engineer with many products under their belt and tons of coaching of others on their track record will easily tell if someone knows what they're doing, especially if they get to pair program together for even 30 minutes.

As soon as you get away from what the interview prep books cover, it's usually pretty easy to tell if someone in your own field is experienced and at least competent, just by talking with them.

(Leetcode seems to be an awful predictor of how someone will perform as a software engineer. That students are spending so much time practicing for it, rather than experimenting and building things, is awful. Some of the biggest companies they're applying to were founded by students doing the opposite of practicing for someone else's hazing rituals -- they were experimenting and building.)

I genuinely believe a 15 minute back and forth between an engineer and an interviewee will give a better signal for hiring than any hours+ long Leetcode 'assignment'.

While this may be true, it takes more than just engineering skill for this to work in a predictable manner. Often an engineering interviewer takes their ego into the process and it becomes a competitive game or an opportunity to show how smart they are.

I 100% agree with you but it's not as easy and scaleable as it seems.

Agreed, interviewer ego slipping in can be a problem.

Interviewer training can help avoid that happening accidentally.

(And Leetcode interviews don't avoid the interviewer ego problem. It's purportedly "objective", but the interviewer can easily taint it, accidentally or intentionally. The answer isn't Leetcode, but to train or reign in egos, and then you can use a real conversation.)

I used to interview like this, until I hired the wrong person. They talked elequently about how to program, but just weren't very good at digging in to technical details of an existing codebase and understanding what was actually going on.

So I added an hour's pair programming on either toy problems or our existing codebase, depending what was suitable at the time. No leetcode, no months of prep for candidates, and our interview outcomes were much better.

There's a massive gulf between toxic leetcode hoop-jumping and a friendly chat.

Leetcode also encourages people to 'roll their own' algorithms and cryptography. Even though most languages have standard libraries which cover all of it already.

"lines of code" is not a pseudo metric. On large scale projects, statistical population density functions emerge, and if you need to manage such a project (like getting to the moon by X date) you can't just throw away the entire field of statistics because it says some things that you personally, anecdotally would like to dispute.

What's a good example of a situation where lines of code written are a high quality signal of software developer performance?

If my company is under contract to your company for a piece of software, and the software we (a team of 100 people) deliver is a million lines of code, and you ask for changes to the software that you believe fall under the contract and we believe do not fall under the contract, in any event the scale of the change, let's say it's 200K lines of code, does offer a pretty good estimate as to how long it takes to change, how much it cost, etc. as compared to the original deliverable, and wether and now such a difference of opinion might be litigated.

It's better compared to many other measures you might think of, though it's an interesting exercise to consider what might work better.

it's not a pseudo metric.

(source: I did some work for a litigation support/consulting firm, expert witnesses for defense contracting)

That's an interesting case that I hadn't thought of, or encountered myself, so thanks for sharing that!

We might be talking past each other here, so please correct me if I'm wrong, but how does the example you presented address the argument that "lines of code produced are not a useful metric for evaluating individual developer performance at hiring time"?

This is the fundamental concept of filtering out bad research by peer review. Work is reviewed by people who know the field well enough to understand a paper.

Ideally we have this by code review, which should, theoretically, filter out the bullshit, but software development, as the original post in this thread says, may be overwhelmingly populated by bullshitters or people who honestly don't know their own lack of ability.

This is exaggerated by agism and completely discounting audited real experience over leetcode and small take home projects.

> but eventually they shit where they eat so much that end up creating an unmaintainable morass and choose to move on.

At a new company with a higher salary. My richest friends are all like this.

A lot of mine, too. Sometimes I wish I could be like them, but there's a lot of things I could do if I didn't have moral quandaries about doing them.

Where is the moral quandary in moving to higher paying jobs? Employment is at will. If your company can't afford to lose you they are welcome to sign you to a long term contract like sports teams do with their players. But they never will because they lose the right to fire you whenever they want. You owe them nothing.

You may never see this, but I want to clarify. I have no qualms about jumping ship; I have and will again. I was referring to the morality of doing bad work and propelling oneself upward on the good work of teammates. Writing code that works but is impossible to maintain and selling oneself as a hero is, in my opinion, a Shitty Thing To Do.

I've been in teams where more than half of the people were, for lack of a better term, quiet bullshitters.

Everything was "difficult" and "required analysis". The code mostly worked, but was full of workarounds that would not have been there if someone spent half an hour reading the library documentation.

One thing they didn't do though was stick their head out too much as that was too great a risk to their cushy positions.

Why do they do that, one might ask? Turns out they're either busy with house renovation or have some kind of engaging hobby which takes most of their time.

I had a guy confess that those three hours between 7am and the end of our standup is the only time he works during the day. He was hard to work with because he would do everything to cover his ass should something go wrong.

> I had a guy confess that those three hours between 7am and the end of our standup is the only time he works during the day. He was hard to work with because he would do everything to cover his ass should something go wrong.

Three to four hours of deep work could be enough to complete the daily workload. Maybe he was downplaying the other rest of time that didn't feel like he worked at all even though he was in meetings and doing other BS the company required him to do.

> Three to four hours of deep work could be enough to complete the daily workload...

only if you make a case that six to eight hours of deep work is somehow not possible. Perhaps you make a good faith effort to get 6 to 8 but you can't seem to do it, or you're too exhausted after 3 or 4, but you can't simply demand that you should get paid for 8 but you're only going to work for 3 or 4 because that's enough.

Unless you are paid hourly I don't see why that should matter even remotely.

> only if you make a case that six to eight hours of deep work is somehow not possible.

6 to 8 hours of deep work is certainly possible but is it sustainable? I don't think so, minds need some slack time, enter a different mode of thinking, etc. For this reason work is chunked into workable amounts which it makes it sustainable as well.

His full statement was that he's doing house renovation later in the day instead of work.

Another situation: we were estimating tasks and I challenged the estimate for a task he was supposed to do.

His reply: "ok, if I'm going to reduce my estimate then you reduce one of yours"

Normally I wouldn't care about such things, but my work depended on his and it was hard to make him follow through on his promises.

"The company way" from the original "How to succeed in business without really trying."

https://www.youtube.com/watch?v=SKC8iPeIvEA

I must admit, for most of my career I've been a "quiet bullshitter". I start with the best intentions but quickly get into situations that are far too difficult for me so I spend a lot of time covering up my problems with work for fear of being fired. ADHD plays a big part too. So I go to the meetings, I talk the talk at the job interviews and then fiddle with my computer getting nothing done all day. I've gone 6 months or more without shipping a line of production code. My code is generally quite bad and I don't know how to fix it, and now I'm in a more senior position it's too difficult to ask for help for extremely basic programming tasks.

My advice: many "quiet bullshitters" want to do better, but lack the tools, support and ability to do so. They're not trying to take everyone for a ride, but they feel backed into a corner with no way out and they can't ask for help without great personal risk (either real or perceived).

If it makes you feel any better I worked with a "Principal" engineer who was afraid of regular expressions.

That is a an interesting insight on BSing and I appreciate you being so upfront about it. Your response is why I like HN so much - you gave me an angle I didn't have to ruminate on.

>I start with the best intentions but quickly get into situations that are far too difficult for me so I spend a lot of time covering up my problems with work for fear of being fired. ADHD plays a big part too.

Things can get very difficult very quick if a company has most of their knowledge stored in people's heads, and the main mode of spreading knowledge is meetings.

Having little documentation is common Having a high meeting culture makes this work for a part of the company, for a while. But even the good listeners at some point aren't sure enough about their knowledge that they would write about it. Making the problem worse.

AD(H)Ders will not be able to process any of this knowledge, because it's all dependent on listening to people. At some point they'll feel ashamed that they are in the project for years now and can't contribute properly.

If you do want to stay in this company, this strategy can work to make your life better:

1) Document everything, for yourself. Since you're ashamed of your lack of knowledge write up in private what you do know, or think you know. Since you keep it private nobody will see if you have something wrong.

2) When you need to something, you can test if this knowledge actually works as you wrote it up, you can refine it.

3) Once refined you can contribute it back to the main knowledge base.

4) If you don't know something, and can't find where it's documented, ask people to show you where it's documented. If it's not it's not a bad thing for a senior engineer to ask where it is documented. This saves face, and improves documentation.

Also: always ask people to write you emails if they want anything from you. Verbal is worthless.

I feel I’m in a similar position. It’s not that I’m not working but I’ll often realize, in hindsight, that I’ve spent way more time on something than it was worth. This kind of single track mind also has me waiting last minute to finish a lot of work when the deadline knocks me straight.

One thing I’m going to try is putting everything into some kind of planner. Like my own personal scrum board. I know your case is a bit different but curious if you’ve found some tips and tricks that helped

I've met such people, hell, I've been such a person and to me this is different in a way that's not visible from the outside and that is (not) giving a single fuck whether this makes life harder for others in the long run.

Paraphrasing something one person told me(not the 3h guy, someone else):

"Look, I'm building a house right now and that's my main focus. I'm billed by the hour so if anyone finds out something is wrong with my work and orders me to fix it, then that's just more billable hours for me. I don't complain - at least there's work."

That last bit is specific to my corner of the world where the previous decades were marked by high unemployment.

is this identical to "fake it till you make it"? so you climbe too high on carier lader and it's scary up there but you also dont want to climb down, ao you expect someone to come help you stay there. dont take this personally, but such cases make me angry, because most of the time it prevents competent but quieter people to rise, and pushes them away from competent deciasion making.

I have similar experience. I am always amazed that there's these rockstar personalities that start projects, hit trouble, and then pivot to a new project without every finishing anything. I kind of find it fascinating that these people are always framed as 'the best' etc etc.

These people are dangerous and the ones I watch for the most. I see them as a somewhat dark manifestation of the "Peter Principle". They are charismatic people full of ambition who want to climb the corporate ladder but lack the skills, leadership ability, and knowledge to actually do so based on merit. Some common behavior I have observed, 1) they never deliver bad news to leadership and are willing to lie or misrepresent to achieve this 2) they never will be responsible for the failing project (which they've caused to fail) and will immediately find a way to move to another project 3) they take credit for all successes regardless of their involvement in those successes 4) over represent their own contributions and constantly talk how busy they are and how little work everyone else is doing.

Combining the above they will move from project to project and position to position once a year or sometimes two years leaving the team or some poor soul who was recently promoted to take over their mess. Then when the project continues to fail they can shake their head to their boss and say, "Everything was on track when I left project. They must have really gone away from the original design for this to happen."

This is why we have to ensure that somebody asks at least one FizzBuzzesque question during interviews, and why you don't want to work at a place that doesn't ask you a FizzBuzzesque question.

That was often what happened when I worked for nontechnical management. There was usually one person with especially good BS skills. That person seldom had decent technical skills, and did all sorts of damage because management would put them in charge. It was endlessly frustrating and management never learned, and the perps would just leave and BS into another job.

Agreed. Financial success and career progression as a software dev has little to do with your talent. It's more about luck and BS ability. Most successful or fast-growing big tech companies can afford to brute-force every problem by throwing tons of developers at them. Most developers tend to produce code which just barely works and is way overcomplicated but it doesn't matter because most fast-growing companies don't have any issues hiring large numbers of developers to patch up the many mistakes by brute force.

This is encouraged by the incentive structure, ship and gtfo is the way to advance.

You will never be punished for shipping, and always punished for not-shipping.

I've never seen somebody get fired for too often being late to ship, but I have seen someone get fired for shipping changes that too often break customer workflows.

> moving the button one pixel to the left can be a week

As an aside, I always find this to be a funny example, because it's the kind of requirement that reeks of design mistakes (either UI design or code design). How did we end up in a place where a button was 1 pixel out of alignment? It can happen innocently enough with a true "defect", I've seen it, but more often it indicates either A) designers are freeforming everything and wasting massive amounts of time or B) engineers are not using reusable styling frameworks/components.

Either way, ending up with a tiny task because a button is 1px out of place probably means you have been wasting hours of work and will continue to waste hours of work if you don't fix it the long way. Doesn't necessarily mean I would stretch that particular ticket out to a week, but I would certainly take a little bit of extra time to make sure we didn't have to fix the exact same problem again next week.

> designers are freeforming everything and wasting massive amounts of time

This is happening at my company. We had built a whole UI library and then the new UI design team came in and started designing everything with zero regard to our existing library. It has been a shitshow.

Bonus points because product likes their new designs more than the premade library, so they are fighting hard to throw out the library. Which we basically just finished building.

Woohoo!

BSer that knows what they’re doing here.

Another unpopular opinion; I’ve resorted to BSing these days cause let’s be real; vast majority of these startups are just fiat wealth rockets, hooking people on nation state scrip

This whole thread just feels like low effort coder bro chest bumping.

What real human problems have you all resolved that lifted the lowest in society without the kowtow to those of high net worth?

We’re just high priests avoiding real work of keeping ourselves alive.

>hooking people on nation state scrip

My eyes cannot roll any harder.

See the word “fiat”…

Ok, bro

> What real human problems have you all resolved that lifted the lowest in society without the kowtow to those of high net worth (another appeal to imagined authority)?

I'll admit that my profession is no more noble than say, a carpenter, and is primarily to fund my desired lifestyle. But I don't work at a startup and I don't make startup money and I'm certainly not a coder bro (after my time). I can't say I've "resolved" any real human problems either, but I do occasionally try to do something to help. Over the years I've coached youth sports, tutored reading and math for underprivileged or ESL kids, collected food for the local food bank, played harmonica in a jug band at the local old-folks home, taught after-school bike repair, do roadside cleanup, and was going to do books for inmates but it got cancelled due to COVID. And lest you think I'm trying to get into heaven this all comes from my cold dead atheist heart in the chest doing all that bumping. ;^)

Companies are welcome to make their interview processes more stringent to weed out bullshitters but they'd have to raise the salaries until they actually get enough non-BS candidates through the door.

That not happening suggests that "BS" is good enough for most companies in which case why should you bust your ass doing any better when it's just more work for yourself and is unlikely to get rewarded adequately?

If they're offering "market-rate" salary then they can get "market-rate" quality, and if BS became the new "market-rate" then I don't see anything wrong with that.

No, if anything, higher salaries just attract better bullshitters.

This is even worse when average people strike it lucky and get on a successful project and get promoted. This leads to boundless bullshit and buzzword soup.

I think daily stand up even encourages BS. Sometimes you really don't get much done in a day, but during standup it's got to sound like you did _something_ -- so how about some bs.

It's the managerial pipeline! Handle it with care because it will never be abolished.

Add to this the amount of aversion to risk and to getting your hands dirty by pumping out code. It is so weird to see SWEs wanting to get into BFUDs before writing a line of disposable code (at least at big cos). Though I am sensing the perf process incentivizes this (impact and artifacts at all costs).