[applepple]

From worst colleague: Succeeding in our modern economy has nothing to do with ability, intelligence or work ethic. It's about luck and intimidation.

From best colleague: 10x, 100x, 1000x... developers are real. I also learned that making bold, controversial claims will yield respect dividends in the future when they turn out to be true. For one of my past startups, I was working closely with the CTO who was at least a 10x or 100x and some of the stuff he was saying seemed to defy a lot of the industry practices at the time. I didn't take what he was saying very seriously at first, but over the years, I ended up discovering that essentially everything he said was true and lead to huge productivity increases. It had a big impact on me to understand that software development is a craft which can be mastered on a whole different plane beyond what the vast majority of developers can imagine. I consider a lot of his teachings to be 'trade secrets' and I try to pass them on to other developers I care about (especially open source collaborators).

[bufferoverflow]

Could you teach us some of his best lessons please?

[applepple]

There are so many. Sometimes they're big picture stuff, sometimes they're more detailed.

One of the lessons I learned in my junior years is that I used to write CSS with a lot of nesting and relatively short class names (I used SCSS which made nesting easier) - The CTO kept telling me that I should avoid using more than 2 levels of nesting and to use long descriptive class names. I felt that was against the whole point of "cascading" in CSS. I soon discovered (during the first redesign) that when you have a lot of nesting in the CSS, it becomes extremely difficult to refactor the layout of the application; moving containers around breaks the layout every time. Whereas if you have a relatively flat CSS, you can move around components easily without breaking anything. It seems so obvious in retrospect.

I also learned the importance of having one source of truth and the importance of making sure that each kind of data flows through the system in a single, clear direction (or else you can get glitchy behaviour with certain kinds of realtime data). A common one is to make sure data flows from the source of truth. For example, when you click a component, it should update the URL hashbang, then other components should react to the change in the URL... Don't make the components react to the click directly and only update the URL hashbang as a side effect (because the click event could conflict with the URL change event in some edge cases; e.g. cause the UI to be rendered twice is a common issue). The URL has to be the source of truth.

Another critical lesson was about separation of concerns and the importance of being able to justify all technical decisions using simple non-technical language.

But there are so many lessons. I was fullstack so I learned a lot of backend tricks as well. A different one seems to come up every day when I work with other developers on a complex project. I try to explain the reason as much as possible because sometimes they sound counterintuitive (or I should say counter-narrative) and they're not usually silver bullets so it's important to convey the nuance as well.

[a_bonobo]

Sounds similar to Ousterhout's Philosophy of Software Design!

https://www.amazon.com.au/Philosophy-Software-Design-John-Ou...

The main point is that a software developer's job is to fix stuff so you end up introducing complexity, but you will have a much easier life if you realise when you're about to introduce more complexity, and try to minimise it by thinking about your implementation choices. KISS, I guess.

[applepple]

Nice, this is a broader way to explain the effectiveness of my CSS approach and many other approaches. IMO, Modern developers should read fewer books about tools and more books about software philosophy. It's far more important.

It's weird to think that philosophy can actually yield productivity gains... Many people think of philosophy as being the anti-thesis of productivity.

[bruce343434]

What do you mean by 10x, 100x, 1000x?

[applepple]

A single developer who can complete projects in the same amount of time as 10 or 100 or 1000 regular developers to at least the same quality standard (but usually to a higher quality standard because code quality is key to getting that productivity gain in the first place and code quality usually translates to project quality).

That said there are projects for which a developer could be infinity-x compared to other regular developers. For example, a highly complex project which regular developers do not have the capacity/talent to complete, ever... Just imagine some very complex project programming a quantum computer or certain kinds of blockchain or distributed systems projects; some developers will never be capable of delivering such projects. It's beyond their innate ability and capacity for learning.

Project complexity maximizes the utility value of highly productive developers. It would be difficult to identify a 100x developer on a simple project (they might only appear as 2x) but they would stand out as a definite 100x on a complex project.

[sombremesa]

The problem with being a 10x or a 100x dev is that you never get paid commensurate to your value. You’re almost always better off (psychologically - unless you have mouths to feed :P) starting a business if you have business/marketing chops at all.

[applepple]

That's not a great option in most cases either. You need social connections or else your product will never sell.