Ivan Lim

Let’s talk Go vs Ruby. I’m generally a fan of languages and frameworks that, by design, get you to good outcomes and help you avoid pitfalls. When you’re working on a codebase over the long term, that means that your code continues to be manageable as more code is added. It also means that what you put into production is reliable and delivers as intended. For many years over my career I’ve loved coding in Ruby. The design and philosophy behind Ruby’s syntax can bring clarity and is genuinely a joy to work with. I tend to learn and experiment in many different languages, but Ruby has tended to be my preference. There’s some major drawbacks with Ruby however. It’s fairly inefficient. You can chew up memory fairly easily particularly when using certain libraries or frameworks. It’s not always obvious that this is happening either due to the abstraction level. Ruby’s code execution is generally slow compared to other languages. Concurrency is problematic. A lack of types and the popularity of the web can mean that some framework authors just whack everything into a string. Yeah that happens. All of that elegance in syntax and expression doesn’t come for free. It means that Ruby can be a poor choice to solve some types of problems. Go isn’t perfect either, but I’ve been coding in Go quite a bit over the past several years. Go is now beginning to be my default starting point on new projects. Go’s speed and efficiency is like another world compared to Ruby. You don’t get quite as much elegance as you do in Ruby. However, some design decisions in Go means there’s less footguns that can bring your code to its knees in production. Typing, errors as values and easy to manage concurrency help reduce unexpected behaviours. Having a compiler is handy to catch problems that you’d require a test for in Ruby. Being able to build native executables across platforms is also pretty awesome. I’m not sure I’m a fan of contexts, in comparison to other Go concepts, contexts feel slightly “magical” as their scope and lifecycle is implied and not explicit. It can be easier to write code in Go that’s hard to for others to understand. The risk is somewhat low due to the simplicity of Go, but it still happens. There’s also a lot of value in the way Go handles versioning and backwards compatibility. It means you don’t get pinged for being an early adopter. Many dev tools historically have made the mistake of breaking changes. The work to port code is not insignificant, and the work has minimal to no value to the customers of a dev team. Considering how much time I had invested in Ruby, my levels of productivity and how much I enjoyed coding in it, I had planned to just stick with it, even in spite of its flaws. I will still code in many other languages, but it’s time to crown a new favourite: Go. Thanks Ruby for your service. We’ve built some cool things over the last 20 years, but it’s time to move on.

29

17 Comments

I'm somewhat regularly challenged on my assertions that JS's type system is actually good (if you learn it) and that you don't need TypeScript to write type-aware JS code. In fact, TypeScript can actually be detrimental to the goal of writing type-aware code. And even more in fact, TypeScript's bar of "type awareness" is too low and too unhelpful for what you should be striving for in your JS programs. I know those are some bold claims. You probably think they're crazy claims.  Did you know that in addition to covering this topic in detail in my "Deep JS Foundations" course on @Frontend Masters, I wrote extensively to explain those claims? Nearly half a chapter worth (10+ pages) in my 2nd Ed YDKJSY book "Types & Grammar". (link in comments) Instead of just dismissing my claims as bogus, I encourage you to spend a little time reading what I wrote and thinking critically for yourself. There's a whole other world of responsible type-aware coding in JS that embraces JS rather than despises it. It's a higher bar I call devs to, to not be lazy and offload their type thinking to a clunky tool like TypeScript. I hope you'll give it some re-thinking.

481

146 Comments

The average time-to-hire for a senior developer is 90 days. That’s three months of interviews, background checks, and onboarding… before a single line of code gets written. So if you start hiring in January, your new devs don’t start shipping until April. That’s *one quarter of your year gone* before your roadmap even moves. We see it every year at Full Scale. Some CTOs start planning in November or December. Others wait until “after the holidays.” The difference isn’t subtle. The early planners are reviewing candidates before Christmas. Their new developers are sprinting by the first week of January. By February, they’re shipping features while everyone else is still waiting for résumés. That’s the real ROI of early capacity planning — you buy time that can’t be recovered later.

71

10 Comments

Learn how to use Unmanaged Files in Drupal for maximum performance and flexibility! In this comprehensive 6-part series, Jeff G. Greenberg shows you step-by-step how to ditch the database overhead and build custom services for fast, clean file handling. Dive into the full series and see how to get a random, category-aware image trio with zero database queries. 🔗 Find the full series on The Drop Times now! https://lnkd.in/ghh75AMQ

7

TypeScript utility types aren't just syntactic sugar, they're the difference between writing types that work and types that scale in production. If you're serious about front-end development in 2025, these 5 utility types will transform how you handle data flow: 👉 Essential Utility Types: 1. Partial<T>: Makes all properties optional Perfect for update forms and PATCH requests 2. Pick<T, K>: Extracts specific properties Ideal for component props and API responses 3. Omit<T, K>: Excludes unwanted properties Clean data sanitization and secure APIs 4. Record<K, T>: Creates key-value mappings Type-safe objects and configurations 5. ReturnType<T>: Extracts function return types Consistent API responses and composable functions The Reality Check Most developers overcomplicate types or avoid them entirely. These 5 utilities handle 90% of real-world type transformations without custom logic. Stop reinventing the wheel. Start building type-safe applications that actually ship. 📌 Ready to master TypeScript fundamentals? Practice these in real projects: https://lnkd.in/gUK5it4Z 💬 Which utility type saves you the most time in daily development? #TypeScript #FrontEndDevelopment #WebDevelopment #TypeSafety #greatfrontend

439

9 Comments

The job market has lost its damn mind, y'all. Coming back from maternity leave, I stepped into what feels like the twilight zone. We went from recruiters begging developers to talk to them to developers struggling to get a single response. What happened? • LinkedIn's "Easy Apply" turned job searching into a numbers game (spoiler: it's not working) • Everyone's using AI to create the same generic content 🚀 (drowning in noise) • Market uncertainty + federal contract cuts = chaos • Companies hitting pause to "wait and see" But here's what I want you to remember: The system is broken, not you. I dive deeper into what's actually happening AND what you can do about it in Monday's The Rogue Newsletter. Including practical steps to stand out and why being "busy" with applications doesn't equal results. Subscribe to get the full breakdown (link next to my name). #gorogue

210

57 Comments

I work a lot with unemployed people through my nonprofit, helping highly educated immigrants find jobs. One of the reasons I fully recommend Cursor for vibe coding is that you can get started for free. The Cursor + GitHub + Vercel stack costs $0 for a very long time. You can build a portfolio site, learn coding, experiment with APIs, or even launch a lightweight SaaS - all without spending anything. It’s one of the most accessible ways to build skills that actually increase your chances of getting hired. This matters because highly educated immigrants face disproportionately high unemployment in Europe. In 2019, foreign-born individuals aged 20–64 in the EU had an unemployment rate of 12.3%, compared to just 6.0% for native-born workers. Nearly half of migrant college graduates across Europe are working in roles below their qualifications. It’s a massive underutilization of talent that costs the economy billions. Lightweight coding education with tools that cost nothing and let people build real products removes nearly all the barriers to learning. With something as simple as browser access and internet skills, anyone can gain career-relevant experience that dramatically improves hiring chances. In a context where credential recognition is tough and opportunities are limited, that kind of access is just priceless and something that individuals should take advantage of.

116

12 Comments

“They didn’t seem to listen or take feedback” A common theme I hear from pair programming. Paired programming is not only a tech evaluation. It’s done to assess communication. How you take on feedback. How you listen to guidance. If you have pair programming interviews upcoming… Hopefully this will help. Listening is an underrated skill. Thoughts? #interviewadvice #pairprogramming #softwareengineering 

18

5 Comments

"Stating the obvious here, but… A decent software engineer can learn any new framework. Yet hiring managers are STILL doing this: "Must have 5+ years React experience" "Expert-level Python required" "Senior Vue.js developer only" Here's what actually matters: → Can they think logically? → Do they understand core programming concepts? → Can they debug when shit breaks? → Are they curious enough to figure things out? Everything else is just syntax. A competent engineer who knows JavaScript doesn't need 5 years to pick up React. Someone who understands Python can tackle Go or Java without their brain melting. Because frameworks are just tools. Programming concepts are universal. But we're still hiring like it's 1995. Writing job specs that eliminate brilliant engineers because they haven't used the exact same tech stack. It's madness. The best engineers I know? They've switched languages more times than I've switched coffee shops. And they're better for it. Stop hiring for specific tools. Start hiring for thinking ability.

71

8 Comments

"Cracked dev" is the 2025 equivalent of Rockstar dev, 10x dev, killer dev or whatever. If you are using this expression in seriousness, either irl or on a job spec, please reassess your ability to perform any sort of hiring based tasks, your overall value to your employer, your career prospects and even your wider life choices. gm

29

8 Comments

I've interviewed thousands of software developers. If I ask a #juniordeveloper how they might approach a task or project, they will immediately dive into detail. They'll hit me with routes and state, responsive this and fluid that 😨 Ask a #seniordeveloper and they will give you high level answers 🤨 They'll pepper the tech, for sure but it's more about how they might approach it than the nuts and bolts themselves. 💡My thoughts on this are that we all immediately jump to the bit that worries them. The senior knows their tech. Now it's just a case of what do you really want? Have I understood the brief and are we on the same page. 👂Listen to the question. If it starts high level, you go in high level also. They can always ask for greater detail on the implementation and tech. ♠️ Are you showing your hand too soon. Too quick to jump to code and the details can be a giveaway that you're nervous about the tech 😬

67

11 Comments

Empowering Education Worldwide with Drupal! Discover how Vardot's Drupal expertise transformed ECW's grant management: ✅ Custom workflows: Streamlined approvals to mirror ECW’s process. ✅ Centralized data: Simplified tracking and reporting. ✅ Enhanced security: Role-based access for teams and grantees. ✅ Strategic rollout: Internal system first, followed by an external portal for real-time updates. Thanks to this seamless solution, displaced communities can access education faster and easier. Hosted by UNICEF, ECW is revolutionizing education for refugees, and Vardot makes it possible! 👉 Explore the full case study: https://hubs.li/Q03bGZw_0

10

Creating smooth, consistent transitions in Vue can quickly become repetitive and messy - especially when managing complex UI states. That’s where vue-transify comes in.⚡️ Built on top of Vue’s native `<Transition>` component, vue-transify helps streamline animation logic by providing a cleaner, more flexible way to define and reuse transitions in your Vue apps. Developed by Pooya Goodarzi, the library is lightweight, easy to integrate, and open source. 🔗 GitHub repo: https://lnkd.in/dyUMPcHT 💡 Live demo: https://lnkd.in/dx96kS4N Give it a try, share your feedback with Pooya, and feel free to contribute or spread the word if you find it useful. 🙌

33

1 Comment