I reckoned at the time, from most interactions on the Internet, that I am (globally) a mediocre, if not below-average, developer - in each discussion I participated online, there were always people above my level, from the ones having a slightly better understanding of the subject to the people whose depth of knowledge appeared somewhat otherworldly.

This belief was particularly strengthened by the fact that I didn't have much contact with real-world developers in real life, as my friends tended to come from different backgrounds.

When the interviews came, I was astonished how many of them couldn't code their way out of a paper bag. The ones who did, wrote code with messed up indentation, inconsistent style, ugly and hackish approaches, and the like. I couldn't imagine how someone could leave their code like that and say "there, this is my finished product." But here they were, and it seemed like they didn't really see anything particularly wrong, or just not important enough to justify the added effort of cleaning the mess up. It was a very strange moment for me.

I believe this to be an example of the classical selection bias: people inclined to participate in online discussions, answer questions on StackOverflow, write blogs and type out detailed technical comments on HN are on average a lot more skilled than the average just-earning-my-living developer fresh out of some half-assed "be a software engineer and make tons of money!" three-month course.

His subsequent (and current) job is now as a very well-known expert as as developer advocate for one of the big four tech companies.

You'd be surprised at what you find developers out there doing, the only good metric on a person being a good developer is writing fundamentally sound code. Literally nothing else matters.

It might be explained by what is know as Yerkes–Dodson law[1], which describes how performance increases with mental arousal up to a certain point then decreases. If different types of tasks correspond with different arousal for different people, then the type of welder or developer one is is orthogonal to their fundamental skill. Instead it would mean that the first type needs to cast the problem as something novel in order to gin up the necessary level of concentration to get the problem done, hence the rock solid code that has sloppy/inconsistent style.

It makes sense that a good advocate would be highly skilled, but the type who has difficulty with necessary work that seems mundane. In other workplaces this might be the person who seems to have low output, but gets their coworkers past their roadblocks.

[1] https://en.wikipedia.org/wiki/Yerkes–Dodson_law

For tech, I usually remember it as AmaGooBookSoft - Amazon, Google, Facebook and Microsoft. Apple is sort of a hardware company so sometimes it is included and sometimes it is not.

For those people, persuading them to indent can be the difference between them having a chance of learning the knack or just flailing randomly, getting frustrated, and giving up.

(The other lesson is: if you're building a DSL for non-programmers, try to avoid putting in nesting and make everything really flat instead.)

Some older books are the worst with indentation. Instead of learning to code you spend most of the time figuring out where the code block ends.

Or at least included a tool to fix it.

As with vim, this depends on being in the right major mode for the language you're working with, which should be automatic for most languages (except Perl, which is screwy, because of course it is), and depends also on that major mode knowing how to cope with the code and being configured the way you want, which should be reasonably trivial for most languages (except Perl, which is screwy, because of course it is).

But don't expect candidates to spontaneously criticize the interviewer's code. Yeah, I know, you want to work with people who can think critically etc, but at the time of interview you aren't coworkers and aren't on equal footing. Personally, if I as a candidate see you writing code with bad indentation I will conclude either (a) you were making a point about e.g. correctness or efficiency and didn't bother to indent because it's literally throwaway code, so mentioning the indentation would be a distraction; or (b) you and your team don't care about indentation at all.

hopefully someone will get around to adding more functionality to the plugin so i don't have to edit my visual studio formatting settings for parentheses/comma spacing whenever i switch projects :p

You sometimes resort to short cuts to meet deadlines.

They, are hacks who don't know how to code.

But yeah I never consider myself to be a great developer until interacting with other developers.

Then I got a job in a bigger company, where because of the nature of the job, I could easily compare with other people in a large team, in the rest of company, and in other companies; and I quickly noticed I was in the top 10% or perhaps even 5%. That was at the same time very surprising and... very appalling, because that meant that all the big titles of those guys were just kind of fake, empty. it felt a bit as if I had been deceived. Even though they had CS degrees, they had vast holes in basic programming know-how an in computer knowledge, and they didn't give a fuck about it, as little as they cared about doing a clean work.

So the people I used to read on Usenet or the Web were indeed exceptions and not the norm, and sometimes pretty much gurus in their domain. Anyway, they were not at all representative of the majority of developers that populate companies.

Keep in mind that following that reasoning, people in the top 1% would feel that your title is fake and empty. Would you then say that it's a fair perspective?

I mean by definition there are only so many 1%ers to go around to fill up top spots.

A CS degree does not confer programming know-how...something about judging a book[1] by its cover comes to mind.

[1] https://en.wikipedia.org/wiki/The_Art_of_Computer_Programmin...

I had always romanticised embedded programming is being the domain of tightly written, well thought out code. I figured there was much less "room for error", so there'd be more scrutiny per functionality. That's been your experience across a few companies?

There are also quite a few programmers who couldn't 'cut it' in web programming, and went over to embedded, where they wreak havoc on small low-cost devices, and another group of programmers who somehow 'fell into' embedded programming many years ago, and have not updated their skills since.

- CTO of a company I worked for (brother in law of the company director) typed with 2 fingers. No Joke

- Senior Software developer to nullify a list, he just creates a "new list" instead of setting it to "null" End result from practical point of view is the same. But the lack of computer science insight baffled me.

- Team lead implements lines of code as a tool to measure productivity. Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed.

LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point.

LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted).

I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc.

Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code.

So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual.

All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.

You should have said that to the team. Especially that if anything goes wrong in project, usually it's new person on the board / junior programmer that gets the blame.

Besides not telling that was just not honest to the team. I think we should all learn from each other, no regard with the job title.

I'm really bad at Math, but CS helped me to understand FP and algorithms a bit more.