Fehim Tabak

As a scaleup, our onboarding sucks. And we probably won’t fix that anytime soon. Still, simply redirecting new members’ focus to where they can already contribute can make a huge difference. We recently had an example of this in our onboarding of new software developers: - New devs have always taken at least 2 months to ramp up, and were not expected to meaningfully contribute to anything before that - Our roadmap is overflowing with feature requests from large potential customers, prioritized as they're our highest growth lever - Most new customers use Barte through our API, with minimal platform interaction. Our front end is usually not a priority - Still, 20% of support tickets were coming from one single front end issue: our search bar simply did not work - With the above, our team couldn’t fix this without slowing growth, even if it was a very simple fix So for months we held the issue manually through support, which doesn’t work as we scale. That’s until Giovani Santos Jr and Marcela Giannella decided to test a process where the ramp up is done by fixing small bugs or known but deprioritised feature requests, with two main hypotheses: 1️⃣ While they'd never win space in our roadmap, small improvements like these have compound effects on customer and overall platform experience 2️⃣ New software developers would gain faster context on our platform and its dependencies faster through this This experiment only took one cycle to know they were right. 𝗙𝗿𝗼𝗺 𝗡𝗼𝘃 𝘁𝗼 𝗙𝗲𝗯, 𝗼𝘂𝗿 𝗺𝗮𝗶𝗻 𝘀𝘂𝗽𝗽𝗼𝗿𝘁 𝗶𝘀𝘀𝘂𝗲 (𝘀𝗲𝗮𝗿𝗰𝗵 𝗯𝗮𝗿) 𝘄𝗲𝗻𝘁 𝗳𝗿𝗼𝗺 𝟮𝟬% 𝘁𝗼 <𝟮.𝟱% 𝗼𝗳 𝘁𝗵𝗲 𝘃𝗼𝗹𝘂𝗺𝗲 𝗼𝗳 𝘁𝗶𝗰𝗸𝗲𝘁𝘀. 𝗜𝗻 𝗮𝗯𝘀𝗼𝗹𝘂𝘁𝗲 𝗻𝘂𝗺𝗯𝗲𝗿𝘀, 𝗶𝘁 𝘄𝗮𝘀 𝗮 >𝟭𝟬𝘅 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗶𝗻 𝘀𝗲𝗮𝗿𝗰𝗵 𝗯𝗮𝗿 𝗿𝗲𝗹𝗮𝘁𝗲𝗱 𝗶𝘀𝘀𝘂𝗲𝘀. So while our formal process still has a lot to improve, a simple refocusing was a clear lever for tech talent to contribute from day one at Barte. As we are hiring 8 new members for our tech team at Barte, I can’t wait to see what new improvements we’ll see in the next cycle.

77

5 Comments

Have you ever wondered why toUpperCase and toLowerCase were deprecated in Kotlin? The original reason was the Turkish language. You see, depending on location, uppercase or lowercase of some letters might differ. The uppercase of i in English is I, but in Türkiye it is İ (notice the dot). As minor as it might look like, it might make a serious difference. Since toUpperCase was under the hood toUpperCase(Locale.getDefault()), the same code might work differently on machines located in different countries. To fix it, Kotlin creators wanted to change actual implementation to toUpperCase(Locale.ROOT), but for backwards compatibility, they renamed the method to uppercase. The same happened with lowercase. BDW, it was a missed occasion to name this function UPPERCASE instead of uppercase. It would break standards, but at least it would be a truly self-descriptive function. This post was inspired by the talk Why we can't have nice things in Kotlin by Vsevolod Tolstopyatov https://lnkd.in/dnKnaKCk

218

15 Comments

The release train of April continues on the Spring team. Today we're releasing Spring Framework 6.2.6, 6.1.19, and 7.0.0-M4. Reminder that our short-term schedule is available on https://lnkd.in/dcfP3agh - For planning, check the milestones page on GitHub.

54

Last year at GitNation Foundation's Amsterdam events, I stood on stage and gave my top tips for landing a promotion. Later, I had an amazing interview with Evangelos-Nikoloas Empochontsif covering a lot of my story and going over those ideas. Over the next few weeks, I'll be sharing clips from both the talk and the interview, in order to give you a thorough overview of what I believe engineers who are looking to get hired or promoted need to do. In the meantime, enjoy this intro which gives a bit of an idea of my background and what we'll be covering. OF COURSE, you can always watch the full interview yourself on YouTube at any time - the link is in the comments :)

41

9 Comments

New blog post: Fluent Internals, Part 4 of Crafting Fluent APIs A good fluent API feels simple, but making it feel that way takes work. In this post, I go behind the scenes of Spring’s RestClient to show how fluent APIs are modeled with types, transitions, and self-referencing generics. The surface may be clean, but the structure underneath is anything but. https://lnkd.in/epGf46TT #SpringFramework #Java #APIDesign #FluentAPIs

24

🎙️ I met a number of Erlang developers at Code BEAM Stockholm yesterday that haven't tried the ELP language server and CLI that we developed at WhatsApp yet. 👀 I admit it, it's not easy to find - especially for VS Code - but it can seriously boost your productivity. ELP is not limited to VS Code, you can also use it with Emacs, Vim and all the other editors that support the LSP protocol. Plus, it comes with a CLI that you can embed in your CI or use from your laptop. 🕺ELP is open source: https://lnkd.in/dJfWDrDX 📖 We have a get started guide at: https://lnkd.in/dGPftjJd 🙋‍♂️ And if you have questions or you are stuck setting it up for your project, we're happy to help. Find us on Slack: https://lnkd.in/dmS_JbXP or open an issue on GitHub: https://lnkd.in/dGt4tExX Help us building a better Erlang developer experience for everyone.

68

4 Comments

Keeping e-commerce fast with Next.js ISR When I worked on an e-commerce site, one challenge was clear: 👉 Product data changes often (price, stock, offers). 👉 But we didn’t want to rebuild the entire app every time something changed. That’s where Incremental Static Regeneration (ISR) in Next.js came to the rescue. ✅ Product pages were pre-rendered as static HTML for speed. ✅ But whenever data changed, ISR quietly regenerated the page in the background. ✅ Users always saw fresh data — without us redeploying the whole project. 💡 The result? Pages loaded blazingly fast and stayed up-to-date. If you’re building an e-commerce site (or anything with frequently changing content), ISR is one of the most underrated superpowers of Next.js. #Nextjs #Ecommerce #WebDevelopment #Frontend #React

10

2 Comments