I'm a seasoned web development expert with a knack for UX design. I specialize in front-end(React), but also do back-end(Node).
I have extensive experience in architecting, building, and delivering large custom-made web applications.
Over the last decade I helped several US/EU based clients build Airbnb-like platforms, real-time GPS vehicle tracking suites, healthcare/finance/construction apps, and more.
I mostly collaborate with tech companies, but also have a lot of positive experiences assuming CTO-for-hire roles to work with non-technical founders.
Tech stack: React.js, JS/TypeScript/Babel, Node, Webpack, GraphQL, ESLint, Cypress.io, styled-components etc.
• Read more on my website: https://getivor.com
• View recent project - Jira Clone (6,4k stars): https://github.com/oldboyxx/jira_clone | Live demo: https://jira.ivorreic.com
• Passion project from 2014 (100k monthly visitors): https://movieo.me/movies
RATE: $150/hour with a minimum budget of $30k.
Get in touch: ivor@codetree.co
You start out with code that will not win any beauty awards but it gets the job done. It's easy to understand by programmers of any seniority, it's simple to debug and reasonably easy to put in an automatic unit test.
Next, you add all kinds of vague, poorly named meta utilities that don't seem to solve any tangible real world problem. You even mess with built-in JS methods like map. The code is now harder to understand and more difficult to debug.
A massive pain is added for some theoretical purity that few even understand or will benefit from. I'll double down on my rebellion by stating that the portability of code is overrated.
Here we're writing code to format notification objects. In our overengineering mindset, we break this down into many pieces and for each piece consider reusability outside this context to be of prime importance.
Why though? Why not just solve the problem directly without these extra self-inflicted goals? The idea that this is a best practice is a disease in our industry.
Most code that is written prematurely as reusable, will in fact never be reused outside its original context. And even if it is reused, that doesn't mean that outcome is so great.
Say that the sub logic to format a user profile link turned out to be needed outside this notification context. Our foresight to have made it reusable in the first place was solid. Now two completely different functional contexts are reusing this logic. Next, the marketing department goes: well actually...you need to add a tracking param specifically for links in the notification context, and only there.
Now your "portability" is a problem. There's various ways to deal with it, and I'm sure we'll pick the most complicated one in the name of some best practice.
After 20 years in the industry, you know how I would write the logic? A single method "formatNotification". It wouldn't weirdly copy the entire object over and over again, it would directly manipulate the object, one piece at a time. Error checking is in the method as well. You can read the entire logic top to bottom without jumping into 7 files. You can safely make changes to it and its intuitive to debug. Any junior would get it in about 2 minutes.
Clear, explicit code that requires minimum cognitive parsing.