As a hiring manager, I used to want to see a profile that competed with my own (at the time).
Now I've learned that (1) burnout is real, (2) work CAN be intellectually stimulating enough to not create that OSS desire, and (3) eventually your job ends at 5 and life takes over.
With that said, I WISH more developers opened issues on the projects they've used.
All too often I've seen people drop one dependency for another due to an edge-case.
Even a simple issue explaining the problem, providing a test case or sample code would be great as an indicator to how a developer approaches problems and seeks help.
What's exciting to me, having tested graph.cool and others, they are fantastic at providing an API in a format that works quite well (GraphQL) and handing the admin for me.
I don't want to build admin anymore.
Frankly, I'll spend more money at the service with the best admin UX.
It's like MixPanel for analytics. I can perform complex queries and analysis with minimal friction, which makes it worth the cost.
"Owning" isn't a selling point for me, when all of the services make it possible to dump the data.
I've struggled with helping people out of this rut.
On the tech side, people come to me with solutions they want to see live, and spend 10x the time there than describing the root problem.
Equally important is asking "why not" to alternative scenarios, as it fleshed out the scope of the root problem, often vetting the initial solution or finding a better one.
The UX is top notch. Not only is the UI polished, but big details like mentioning someone and an invite link appearing is awesome. Or force-pinging someone on DnD because of an emergency.
Slack is seriously user-centric, all the way down to how they run their Twitter.
I was able to rebuild a week's worth of Redux work in MobX within a day. And that's having never used it before.
What's crazy is how MobX is able to update React child components without updating the parent first. It knows which properties are accessed in each component, and ensures only the ones that rely on the changed data are updated.
I'd say give it a shot the next time you have a component with internal state. Not having to worry about the reducer or how the component gets updated is refreshing.
We have dozens of Node projects at my office, and you can tell the age of them by whether the start script is "grunt", "gulp", "npm run dev" or "npm start".
Using [per-env][0], we've begun replacing all setup and all starts for every environment to be "npm install" and "npm start".
I'm guilty of this. I was in a 1.5 hour meeting that started out relevant, but then the conversation devolved into tons of specifics on how the reports were gathered and created, and I went straight to the phone.
It seems the greatest burden on the organizer is the same as a presenter: how do you present the information in an impactful, terse way with the least "noise" so that attendees are inclined not to seek distractions?
One thing I know for sure, sitting on a single slide for 5 full minutes feels like a slog.
We provide 3rd party widgets to sites and originally built them all to leverage jQuery, which has been on 100% of them so far.
However, we prefer React components. Within a week, we were able to convert the jQuery widgets into React components and bundle with Preact.
What's funny is that it ended up being a smaller bundle due to complex logic it took to make jQuery render and update the DOM from existing state. (React's bread and butter)