Dmytro Z.

Your job title is just a label. Your real career? It’s made of problems you’ve solved, lessons you’ve learned, and value you’ve delivered. I’ve seen people with fancy titles do the bare minimum. And I’ve seen quiet developers solve problems that saved entire projects. So here’s a reminder: - You’re not defined by your role. - You’re defined by your impact. - And you grow by what you overcome, not just what you’re called. Your story is built in: - The late-night bug you fixed - The feature you delivered under pressure - The chaos you turned into clarity - The times you showed up when it mattered 👊 That’s your real resume. Title or no title — make it count. #CareerGrowth #ImpactOverTitle #TechLife #ProblemSolvers #MindsetMatters #DeveloperJourney #RealWork #GrowthMindset #ValueDriven #BuildBetter

8

1 Comment

Blogged: Running .NET in the browser without Blazor https://lnkd.in/evWSFYgR In this post I show how to run .NET in your browser without using Blazor, and instead rely on lower-level abstractions provided by [JSImport] and [JSExport] #dotnet #aspnetcore #wasm #webassembly

70

1 Comment

WaitGroup is leaving us 😞😞😞 With the new Go release, we might not require WaitGroup.Add and WaitGroup.Done. Earlier, to manage goroutines, we had to manually call wg.Add(1) before starting a goroutine and then signal completion with wg.Done(). Now, with the new wg.Go() feature, Go will handle all of that internally. Interestingly, this pattern has existed in the Uber Fx framework since day one 🫡🫡 Curious to hear your thoughts on this shift… Old method var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() fmt.Println("go is awesome") }() wg.Add(1) go func() { defer wg.Done() fmt.Println("cats are cute") }() wg.Wait() fmt.Println("done") #golang #waitgroups

72

16 Comments

Frontend work gets more interesting the longer you do it. At some point, it stops being about how to build things and starts being about why you build them that way. I’ve learned to care less about clever solutions and more about: - clarity - accessibility - long-term maintainability The best UI decisions are usually the quiet ones — the ones users never notice, but teams feel every day. This mindset shows up a lot in the projects I’ve been building lately. #FrontendDevelopment #UIEngineering #Accessibility #WebDevelopment #ProductThinking

23

2 Comments

It’s finally here! After a lot of work on the DX and internal architecture, the new documentation for Rikta is now live. Rikta is my take on what a modern TypeScript backend should feel like: fast, type-safe by default, and zero-config. Would love for you guys to take a look and roast the docs! #buildinpublic #typescript #developer #opensource

24

4 Comments

Our beloved profession of building software is fading away. We are currently in a short transition phase where “typing code” is already fully automated, but there is still a capable person needed to steer the agent. Call it an architect, senior developer, or whatever you like. If you actually practice spec-driven development, you will notice something important: the agents get dramatically better over time in asking the right questions and providing perfect recommendations. Not slightly better, but an order of magnitude better compared to just a few months ago. As a result, they need less and less steering. Mid-term, even the role of the capable architect will no longer be needed. Today, architecture, SOLID, and Clean Code still matter a lot, mainly because of how agents work right now. But this will fade as well. Similar to how no TypeScript developer cares about compiled JavaScript anymore because it simply works, these concerns will increasingly disappear from daily relevance. Some argue that humans will still be needed to maintain or operate the software. I strongly disagree. Coding agents can do far more than writing code. They can be connected to monitoring systems, observe customer behavior, ingest logs, learn from them, and continuously improve the system on their own. They can even automate marketing if you like. Others bring up security or the classic “someone needs to get up at 4am when it fails” argument. If that is required for your application, then you are not really leveraging coding agents yet. These systems can already protect applications proactively when running alongside them. This is not common practice today, but it works, and tools like Claude Agent SDK are explicitly designed for exactly these scenarios. So what is left for a software developer? From an economic perspective, not much. It will no longer make sense to pay salaries for a profession whose core output can be produced better, faster, and cheaper by machines. This does not mean there will be no jobs in the future. There will be new ones, but not for everyone. If you want to stay relevant and be part of what comes next, you will need to stay very close to this development and adapt early.

80

38 Comments

A simple but meaningful contribution to Rails demonstrates the framework's continued attention to developer experience - dark mode support for the default welcome page. This first-time contribution from developer Frexuz highlights how Rails maintainers value quality-of-life improvements. The contribution story: Developer Frexuz, after "going over to the dark side," noticed the Rails welcome page lacked dark mode styling. Since their startup script always opens localhost:3000, they saw the screen frequently and decided to contribute a solution. Why small contributions matter: Rails' approach to accepting cosmetic improvements - from Safari drop shadow fixes to responsive design enhancements - reflects the framework's philosophy that developer experience matters at every level. The contribution process: 🔹 Clear problem identification and personal motivation 🔹 Simple, focused solution addressing one specific issue 🔹 Following established contribution patterns and guidelines 🔹 Quick review and merge by core maintainer byroot Community-driven development: This contribution exemplifies Rails' inclusive approach to development. First-time contributors can make meaningful improvements that benefit thousands of developers worldwide. The change improves the experience for anyone using dark mode during development. Developer experience focus: Rails continues prioritising developer happiness through attention to details. Whether it's major framework features or simple styling improvements, the community values contributions that make daily development more pleasant. The broader pattern: Rails accepts contributions that solve real problems experienced by developers. This particular fix addresses a common modern workflow where developers use dark mode extensively and frequently interact with local development servers. This approach - welcoming meaningful improvements regardless of scope - helps maintain Rails' reputation for developer-centric design and community collaboration. What small improvements have enhanced your Rails development experience? We're connecting with developers who appreciate both major framework capabilities and thoughtful details that improve daily workflows. #RubyOnRails #OpenSource #DeveloperExperience #Community #FirstTimeContribution #TechRecruitment

10

🧠 Great developers write clean code. 💡 Exceptional developers bridge the gap between technology and business outcomes. At Lumenalta, we believe soft skills are what elevate devs from individual contributors to trusted experts, advisors, and even future CTOs. Whether it’s communicating trade-offs to a product manager, staying calm when production breaks, or proposing a more efficient solution that saves the client money—soft skills are what multiply impact. In our latest blog, we dive into: ✔️ The soft skills that matter most (think: communication, empathy, strategic thinking) ✔️ How we help engineers grow beyond the code ✔️What it really means to shift from “order-taker” to strategic problem solver If you’re a developer looking to level up—or a business leader looking for engineers who think like partners—this one’s worth a read: https://vist.ly/3n4962h #SoftwareEngineering #ConsultingMindset #SoftSkills #TechCareers #Lumenalta #EngineeringExcellence #RemoteWork #DeveloperGrowth

13

How to showcase your achievements, not just skills. In a crowded .NET market, listing tools and frameworks isn’t enough. Clients want to know the impact you’ve made. Did you improve system performance by 30%? Say it. Did you mentor juniors and help a team grow? Say it. Did you deliver a project ahead of time or under budget? Say it. These details don’t come across as bragging. They come across as clarity. Because a skill shows what you’ve learned. An achievement shows what you can deliver. And that difference is what gets you hired.

12

2 Comments

"It's great working with an EM who cares so much about product," said Senior Product Manager Tanja Lembcke as my probation time at HelloBetter was ending. But I also could have flipped it onto her... 👀 Because "It's awesome working with a PM who cares so much about tech"; something at which she truly excels. Together, we're a strong force. Most of that relationship has happened quite naturally, but there are also things I've realised help us along in the process that I wanted to share with you all: product managers and engineering managers alike! 1. As a Team Lead or Engineering Manager, you need to act as the intersection of business goals, the engineers/team, and product. Not only should you be using your product, but you should also be critiquing it, actively asking questions about it, and constantly coming back to the "Why?". 🧐 2. As a Product Owner or Product Manager, you should be insisting on clear explanations of value for technical initiatives. That means forcing the engineers (or the EM) to explain to you, step-by-step, exactly what is happening and again... WHY. 👏 Don't let them get away with throwing tech terminology at you: get them to break it all down for you in a way you truly understand! 3. Come up with ways to build in technical initiatives: No tech stack is perfect, and no code is forever. Packages change, browsers and devices change, user needs change, and business needs change. You need to be structured in your planning, but leave significant space (I would say a minimum of 20%) for technical initiatives. And that's AFTER leaving buffer for bug fixes! 🐛 4. Constantly talk timing and priorities. Again, these can change at the drop of a hat, especially in an industry like healthcare and DTx where regulatory bodies can drop new requirements on you quite suddenly, or market opportunities suddenly appear. Every week, Tanja and I are discussing what's coming up, what's planned, what's changing, what needs to be bumped down. This is not just based on our own goals, but on those of the company at large. 🚀 5. You should both be absolutely upfront about what you don't know. EMs and PMs should be comparing notes on goals and priorities, but also on blockers and knowledge gaps. If you're still at the point of feeling like you have to pretend to "know it all" with your EM/PM, your partnership is not as strong as it should be. Be brave, and be the first to reveal your own weaknesses so you can bridge those gaps together. I promise it is much healthier and a much faster way to progress in your team's goals. 💪 --- What have I missed? What helps you to connect product and tech meaningfully in a team environment? #TechAndProduct #ProductEngineering #ProductManagement #EngineeringManagement

52

13 Comments