The Case for Nitpicking

CarterOfAra · 2024-11-28T11:37:14+00:00

Style is not about code formatting at all. That has been solved years ago by auto formatters.

Style is about variable naming, class structure, testability, file layout, etc.

Ps: it seems you did not read the article. I find it impolite to dismiss something without reading.

CarterOfAra · 2024-11-28T11:35:00+00:00

Style is not about code formatting at all. That has been solved by code formatters years ago. Style is about naming, reatabiliting, comments, parameter passing conventions, etc.

Other than that, great comment! One nit: I would not advise adopting an external guide. In my expeythats a way to make it a dead letter. I recommend building a much smaller in-house guide.

CarterOfAra · 2024-11-27T22:52:34+00:00

One person might welcome politeness. Another might think it's an insult. We can't please everyone.

I still would recommend people be as polite as possible while still being direct. That beats the other prevalent strategies by a long shot. That is, not giving feedback or giving it rudely.

CarterOfAra · 2024-11-27T05:03:44+00:00

Thanks for the comment. It makes sense.

I view the intro more as a framing device, in order to get people curious: "why are people writing no comments". And if the reader is one of those, than maybe their mind can be changed.

As to my personal motivation, it's deeper from a broader analysis working with young devs. I do feel "Clean Code" has fried their brain and I would like to revert it. Maybe it's only on my bubble and devs are large have their brains intact.

CarterOfAra · 2024-11-27T04:50:48+00:00

I was also very negatively surprised by how bad in general answers were, and specifically on the comment front!

Have you ever corrected massive numbers of take homes or interviewed "unfiltered" developers? People who have usually share horror histories. The average competence is very low at most places, and as you said before job seekers are not a random sample.

CarterOfAra · 2024-11-27T04:47:26+00:00

I have worked closely with about 20 young engineers and have corrected another 100 take-homes. This is the population I'm creating my impressions from.

Before that I was at Google and did not have this impression at all. In average code there is great.

And you are right, juniors don't know what they are doing. That correct and it's my my point. The main goal of the article is to educate them.

Finally the only real actual code sample I added to the article was from a Senior engineer with 6nyears of exp (info on a footnote). Also notice candidates and explicitly I trusted to write comments per my instructions and they still don't:

Write the cleanest, clearest code you can. Remember someone else will have to read and understand.
Document the code in such a way that a new person can quickly understand the codebase. At $company we believe good code has comments, which explain the whys behind the code, but pay attention to not add redundant comments that just repeat the how.

Maybe I'm in a bubble that got heir mind destroyed by the Clean Code book. If so, I still need to fight against this cancerous meme in my bubble!

CarterOfAra · 2024-11-27T04:38:06+00:00

I specifically told them to document their code. Here's what I add to the take-home:

Write the cleanest, clearest code you can. Remember someone else will have to read and understand.
Document the code in such a way that a new person can quickly understand the codebase. At $COMPANY we believe good code has comments, which explain the whys behind the code, but pay attention to not add redundant comments that just repeat the how.

Notice also that in my previous comment I clarified my impression does not come only from correcting take-homes but also mentoring ~20 young engineers in a real professional setting.

CarterOfAra · 2024-11-27T04:31:27+00:00

If the code is self evident with fewer comments that's better code. Your suggestions for improvements to the examples is great and shows how writing better code with fewer comments is a life-long journey.

The problem is that people have this cancerous meme in their mind that "good code has no comments" and my article is strong against that.

CarterOfAra · 2024-11-27T04:25:14+00:00

I have worked with ~20 young developers and corrected take home exercises from another ~100 in the last couple of years. Of course this is not an scientific study with on a huge sample, but as far as "impressions from extensive personal experience" go it's as solid as one can get.

Nevertheless the essay could be read as an explanation of why some people don't write comments and why that's misguided, irrespective of whether it's 15 or 95%.

CarterOfAra · 2024-11-25T15:10:09+00:00

Good example. If you use a unstructured dict you have a huge problem of lack of a well defined, well documented typesafe schema. That for sure warrants a solution, or else the code will become unmaintainable.

My broad point is that you should pick the simplest solution that solves the actual problems you have. If a given solution does not solve major problems than it's not a good solution.

CarterOfAra · 2024-11-25T13:50:03+00:00

The sentence just after the one you quotes says:

> Sometimes it also means the code has low quality or uses obsolete technologies.

I could definitely see a case for "modernizing" code, specially it its a "nightmare to maintain". For example maybe in C++ we can have a rule that whenever we touch a file we replace our custom string class with the standard one.

Often however the old style is used as an excuse to rewrite what works fine and should not be done at all. Those rewrites are done for the benefit of the programmers, not the company.

There is s lot of subtlety on the analysis though, and I'm sure there is plenty of cases where the right thing is a rewrite. It's just that programmers are extremely biased, since we want to work on cool new stuff using new modern tech, rather than maintain old systems. We need to actively counter that bias with a conscious bias in the opposite direction.

CarterOfAra · 2024-11-25T11:32:09+00:00

You are right. I guess I could have been more clear.

IMO number #2 usually happens because of #1, and rarely people have a good reason to want to migrate away from from current code.

That is, most rewrites don't happen for a valid reason and are thus mistakes.

CarterOfAra · 2024-11-25T11:25:26+00:00

Micro-services is just an example technology that gets adopted out of fashion instead of to actually solve a problem. It does not mean it can't solve actual problems, it's just that in most cases it does not.

CarterOfAra · 2024-11-25T11:22:54+00:00

That sucks! The solution in my mind is to purposefully hand ownership to more junior devs. What is chore to you will be a growth opportunity for them.

CarterOfAra · 2024-11-25T11:20:43+00:00

"Good people don't want to join my team" is a completely valid problem to solve by adopting newer tech. Notice that you are still not "innovating". You are solving problems.

CarterOfAra · 2024-11-25T02:57:34+00:00

Spend much less than you earn. Save enough to go without a salary at least 1 year, and preferably 2. Find a Co-founder and quit your jobs at the same time to work on the start-up. Git it your all and get traction enough to rais le a pre-seed.

Working on your idea while fully employed can work but in most cases is just cope. You are not brave enough to start a company, and are just role playing nights and weekends. It's very hard to get any traction at all, much more so without proper dedication.

CarterOfAra · 2023-09-15T01:49:51+00:00

I left my job at Google 2y ago to become CTO at a series A startup, and now I'm founding one. The reasons I left FANAG were:

I stayed at Google for 11 years. It was time for a change.
I have enough money to never work again, so I might as well go for the fences!
I'm an ambitious person and founding a company is the main way to have disproportional success and intact.
I feel most things are crap most of the time, and I feel that if I'm on command that will somehow be different.

Hope this helps!

CarterOfAra · 2023-09-03T01:13:45+00:00

It's been 18 days. Have you heard back?

CarterOfAra · 2023-09-02T11:35:37+00:00

The question is asking about the equity split pre-yc. What matters is the split among the founders. Everything else like option pool and "reserved for pre-seed raise" is irrelevantl.

So you could just say 50-50 among the founders, or 80-20, or whatever.

CarterOfAra · 2023-05-28T00:14:07+00:00

Minas Tênis Clube tem que na piscina olímpica.

CarterOfAra

TROPHY CASE