"Leaders are tool builders" reads like someone trying to convince themselves of their own marketing hype. It's a generalisation that certainly doesn't stand up to scrutiny.<p>Martin Luther King, for example, was a leader, and he's not known for his tool-crafting prowess.<p>Some leaders create tools. Some people who aren't, or wouldn't consider themselves to be leaders, make tools.
The author is getting a bit of heat, and I think rightfully so. Here is the "tool" he's all bragging about: <a href="https://github.com/kennyfrc/cami.js/blob/master/src/cami.js">https://github.com/kennyfrc/cami.js/blob/master/src/cami.js</a><p>The whole thing is 250 Loc half of which is comments. And not to discount on that (Redux itself is not that big, though the ecosystem is). But this tool/project could be just a few blog posts where the author explains the patterns/libraries he is using.<p>It also doesn't help that his blog post/tool has the highest concentration of buzzword language you can expect. Please don't do that.
I understand building something novel (even if it's crazy), but this is just yet another framework using observables + redux pattern. It's been done to death, and imo I don't even think it's that good of a paradigm, in spite of it being <i>everywhere</i> these days.<p>To be a leader, you need to have at least <i>some</i> opinionated design decisions. This is just bandwagoning at its finest. (Bring back global objects!)
The reasoning feels 'off' to me. They created a framework because the author wanted to be a leader, and because Meta's initial motivation was their ad manager... but those are philosophy/ideology reasons, not actual technical reasons. React is indeed complicated that is true, however other frameworks exist, which are also popular, and easier to work with, and to find answers for. I feel that's a pretty important factor - if you are spending your people time on building and maintaining a framework, that's time not being spent on other parts of the business.
It is sad to me that there seems to be a need to justify <i>not</i> using existing tools. Everyone should feel free to do their own thing within a community. This is a good example poorly expressed I my opinion.
Many of us who like to learn software internals have built a JavaScript framework once or twice. And for that spirit of digging into how things work, I applaud the author! Maybe in time they'll be digging into how compilers and web browsers work.<p>I can't explain why exactly I think it's hubris to introduce this at your workplace, but I at least wanted to cheer on the effort to learn how things work under the hood.
“For non-technical folks, Cami.js is a code library that aims to maximize developer productivity - providing the power of Meta's React.js with the simplicity of lightweight libraries like jQuery. I wanted a framework with React's capabilities without all the complexity.”<p>I don’t think non-people will understand this. Seems to be aimed at that product owner, who has done some hobby programming for 2 months and keeps up with the buzz words so to be able to say “hey, I’m like one of you devs!”
I think the title is another sensible variation of tech leads as workflow-unblockers, corner-uncutters and process-robustifiers. For all of these functions, however, you still need good judgment.<p>I do wonder what exactly this particular choice, a micro framework, unblocks? I’m reading some broad concerns about the provenance of React but it’s not clear that’s grounded in a need of the team.<p>There are some challenging dynamics on the horizon for this team…I’d be keen to hear how this goes, six or twelve months on.
I wonder if the author really meant thought leaders, not just leaders.<p>At least in the web dev space, framework and tool authors are often looked to as thought leaders.<p>There's definitely something to be said for an opinion after taking action and learning the lessons of building a framework, but it does set a perverse incentive to build yet another framework if you want your opinion to be heard.
Leaders build systems that build tools.<p>They sometimes build the tools themselves if communication /finding help would take more effort and time than diy.<p>Any other deployment indicates waste (e.g. ego / needing to show off your awesomeness, or needing to upskill yourself because you aren't the right skill-shape for the job) or a company starved for capital that is sacrificing the long term for the short in order to survive.
Nice ego buddy. Are you going to write form validation, i18n, date picker, request fetching and caching and myriad other libraries for your team?<p>You know why other leaders choose React? Because other people wrote that shit already and their team can focus on the business domain.