More from Vladimir Klepov as a Coder
My name is Vladimir, and I'm an engineering manager of a team building a banking app. Following the success of our core banking product, we've decided to expand to other financial services. In the last four months my team has grown 4x, going from a 4-person team to 4 teams totalling 15 people. It was, frankly, a shitshow, and now I see many things we could have done better. At first sight, increasing your team is a perfect way to speed up your product development. In practice, scaling is very challenging. Today, I'll share the pains of growth we've ran into: Disbalanced growth across functions. Teams becoming too large to manage. Processes breaking down. Mass onboarding challenges. Seniority skew. Now that it's all done, I can't say these problems were unexpected, or that our solutions have been incredibly inventive, but a first-hand account is worth writing down. Whether you're a leader expecting your team to scale, or just curious about the daily challenges of an engineering manager, hope you'll find something for yourself. Let's go! Scale evenly across functions You lead a 5-man engineering team. You'd like to build 2x the stuff you're building. The obvious solution is to hire 5 more engineers. Problem solved? Not so fast. Anything you build flows across several stages, each handled by a certain role, for example: product manager -> design -> engineering -> QA -> product analytics -> (back to) product manager. If you have a balanced flow with your current team, enlarging just the engineering will not make you more productive: Downstream functions (QA / analytics) can't keep up with the increased production — they must either put in overtime or downgrade quality standards. Upstream functions (product / design) can't fill the backlog fast enough, and the eng team has nothing to focus on, either slacking or refactoring the refactorings. With rapid growth, some temporary disbalances are unavoidable. It's fine to spend a few weeks or months in a disproportionate state, but overall aim for balanced scaling. Here are some tips to smooth the transition and even use the disbalance to your advantage: If you have any control over it, give product & design a hiring head-start. You can get their artifacts ready for development with a limited series of grooming meetings, and once the new engineers are on board, you'll have some great useful tasks to feed them. Catch up on your tech debt. Have too many engineers and not enough product tasks? Don't despair: use the time to clean up some old bugs, do the overdue refactorings, and prepare the codebase for the speed-up. Expand the area of responsibility. If you lack QA specialists, it might be time for the engineers to practice their testing skills. Oversized non-technical component (product / design) is more problematic, but you can give them some no-code tools to replace the eng team in some scenarios — e.g. build an admin UI where PM can edit the texts, create new banners, and so on, without involving your team. Update team structure Say you have a normal-sized team (4–7 engineers) with your average meeting structure (whole-team planning, grooming, and retro + weekly 1x1 with every team member). Making it a 15-person team won't work at all. An hour-long 4-person retro has 10 minutes of speaking time per member — enough to make a point. In a 15-person retro, it's 3 minutes — not practical. You either exclude some people, or extend the meetings — both poor options. It's harder to agree on any decision, because you now have 3x the possible objections. The 1x1s alone eat up 7 hours (almost a full day!) of your time a week. Managing communication of 15 people plus all the external stakeholders is time-consuming. The team must be split. What does it mean to be a separate team, anyways? Ever heard of "high cohesion and low coupling" principle in software architecture? I think this also applies to teams: Shared information space. Team members know what you're working on, where you're going, who your peers are, the system structure and so on. Own a well-defined part of the product and the codebase. A look at a random feature is enough to guess the responsible team. Control your processes — meeting structure, releases, etc. You can't be responsible for what you can't control. Have all the capabilities needed for your day-to-day work. Begging someone each time you need to deploy, change the API or add a banner is not very effective. It's best to split by product domain: customer acquisition team owns the landing page and signup, daily banking team owns the main app, and so on. You could split by layer (product + infra) or by function (backend + frontend + mobile) — I feel these compromise points 2 and 4, but let's not die on this hill today. At any rate, a team over 8–10 people must be split into sane-sized chunks to keep going. A note on grouping You can split a team by (A) building the new team out of newbies or (B) mixing newbies and oldies in each new part. Prefer mixing: it distributes the knowledge across the organization, and the social connections from the original team prevent siloing. You could argue that (A) keeps the original high-performing team intact, but it does so by slowing down the new team and undermining your long-term flexibility. Where to get new leaders? Splitting a team into 3 parts creates 2–4 leadership positions, depending on your place in the new structure. Ideally, you have senior members of the original team to lead the new teams, because it's a rare opportunity for career growth on a management track, and they can easily hire and onboard new members of their teams. If you don't have a suitable candidate (everyone is either very junior, or hates management), it's fine to hire externally — following a few hiccups, I recommend hiring people with prior leadership experience, because adjusting to a new product and a new role at once can be too much. Split iteratively You don't have to produce a fully separate team right away. As usual, move step by step — you get faster results, and can adapt to the issues that arise. Here's one possible sequence: Assemble a domain team, appoint one as the lead (you can call it trial-lead, to give them a chance to cop out). See how they like their new roles, and if the headcount needs tweaking. Run a retro for the new team to catch communication issues or cross-team dependencies early. Separate the domain backlog and kanban boards (or wherever you track the tasks). You'll need it for further process splitting, and to assess the team's load and velocity. Split planning and daily meetings, so that the teams don't waste each other's time on discussing irrelevant tasks. Gradually transfer the remaining processes (1x1s, onboarding, postmortems) to the new lead. Split the codebase, so that the new team can fully own its service. Update your processes Just like your single-team structure, the processes you have will likely fail for a larger team, especially if you have many newbies. Example: we had a liberal release process — if you want some feature in production, you deploy it. As the team grew, the release frequency dropped — the newbies were afraid to touch prod, the oldies were hoping one of the other 14 people would do it. Before I give you my solution to this puzzle, let's look at the general advice for process scaling. Localize processes to the new teams. Owning processes makes a team more effective. Retros, plannings, kickoffs, demos, daily stand-ups, releases, documenting, on-call duty, whatever you can split, do split. Yes, your overall team loses sight of the stuff going on across the system, causing duplication and poor decisions, but in return we can focus on a specific business area, and maximize productive time instead of drowning in discussions. If you need to offset the downsides, introduce a cross-team sync here and there (still working on this one). Let the new teams experiment with processes. What worked for your original team doesn't matter, that team is dead and gone. What works for one of your teams won't necessarily work for the other, because they work in different conditions. For example, our CA team has many time-bound tasks from marketing. The core banking team focuses on building quality software, and fixing the bugs as they arise. Very different teams. Start with a copy of your current processes (just to start somewhere!), and introduce team retros as early as possible to tweak the process as needed. Stricten the centralized processes. Back to our problem with deployment — we couldn't isolate the release process to sub-teams, because splitting a monolithic front-end into independently deployable parts is technically challenging. We introduced a more structured release process: The releases are automatically built and ready to deploy every morning. No more decisions to make. Daily rotation of release managers responsible for getting the release to production. With regular training, you get better at releasing. The release process is clearly documented. The newbies have a clear path to follow, making it less stressful. This works for other centralized processes — writing documentation, debugging with customer support, maintaining shared libs. Overall: hand over as much process as you can to the sub-teams, and introduce clear rules for the remaining centralized processes. The onboarding valley Surprisingly, fast hiring can reduce your team's productivity in the short term. The newbies are not yet up to speed, and the oldies now spend time explaining your codebase and reviewing code. This will fix itself over time, but here are a few strategies to get past the bump faster. Prefer slower growth. Adding one person every few weeks is much better than adding 6 people simultaneously, because: The "onboarding load" stretched over time occupies a smaller share of your team's resource. A few weeks in, new hires can already help onboard someone else. In some cases, they'll do a better job than any oldie, because their memories of one-off tasks like setting up the dev environment are fresh. Every onboarding exposes new roadblocks in your process, helping you smooth the next ones. On paper, batch onboarding might seem like a time-saver, as you can make a lecture explaining the basics to many people at once. In practice, unless your product is very small, or the tasks are very repetitive, every newbie faces very different challenges, drowning you with a wave of questions. Encourage peer-to-peer onboarding. As a leader, you might think onboarding is your personal responsibility. I call BS — peer-to-peer onboarding is clearly better: More "onboarding resource" leads to faster, better onboarding. The load on you, personally, decreases, freeing time to do other impactful things and, you know, live. Team members get a safe environment to practice their mentorship skills. People get to know each other, instead of only talking to you. ICs with recent hands-on experience do a better job at explaining the specifics than you. You can pair a formal "mentor" to every newbie, or direct questions to a team group chat. If you want to control the overall onboarding, at least route specific questions to team members experienced in that area instead of trying to come up with all the answers yourself. Write the docs. The best way to make onboardings cheaper is writing stuff down instead of explaining it over and over again, with your mouth. Some particular things to focus on: Onboarding checklist — the things every new team member must do: get a VPN certificate from the security dude, join this and that chat, clone a repo here and there, boom you're done. Only include essential steps — adding somewhat useful stuff obscures the actually important things. Document your existing business processes, system architecture, technical conventions, team and communication structure. It's better than explaining in real-time, because you get higher-quality charts, relevant links, and you can collaborate to put the knowledge of multiple team members in one place. Tooling and automation. The more automated a process or convention is, the less onboarding you need. Example: if you build your releases locally and upload somewhere via FTP using the keys you get from Piotr the devops, it's time to set up decent CD instead of documenting the current state of affairs. Pro tip: encourage newbies to improve and update the docs as they follow along — it's a great first contribution to your team! Senior vs junior hires It seems sensible to focus exclusively on senior hires. Experienced engineers get up to speed quicker, because they're already familiar with the basics, have a lower risk of making catastrophically poor decisions, and can bring good practices and ideas from across the industry to your team. Not so fast — here are some reasons to hire junior developers. With little exposure to the industry, they can easily adapt to whatever culture and processes you have. Anyone on your team can mentor a junior hire, while getting e.g. a junior engineer with decent knowledge of the product to mentor a newly hired senior engineer might be awkward, not very productive, or even taken as an insult. And of course, you can hire more junior engineers on the same budget. Overall, aim for a balanced team composition in the mid-term. You don't want your team to be a kindergarten, but a nursing home is no good either. Remember that people tend to gain experience, so the junior engineers you hire will become middle in no time. Today, we've discussed the challenges of rapid team growth — and ways to address them: Hiring more engineers won't speed you up unless product, design and QA grow to match. Start by growing product & design. If product lags behind, use the spare time to clean up the tech debt. Expand the area of responsibility of the oversized roles. Teams over 8–10 people are hard to manage. Split into chunks of 3–7 people, preferably by business domain. Mix old and new members in each team. Split step-by-step instead of going all in. The processes of your original team won't accommodate a larger team. Localize the processes to the sub-teams as much as possible. Let the teams tweak their processes to suit their needs. Stricten the remaining centralized processes. Onboarding is time-consuming, and can slow you down. Go slow: onboarding a person every week is easier than 6 people at once. Write the docs instead of explaining stuff over and over. Peer-to-peer knowledge transfer is better than onboarding everyone personally. Hiring only senior engineers is not a silver bullet. Aim for a healthy experience distribution in the mid-term. Hope these tips help you get past the scaling issues and up to speed in no time.
It's been almost 2 years since I moved to a team lead role, then to a full-time engineering management position after the expansion of our team. I've been a front-end developer for 7 years before that, and initially I took the "advanced individual contributor" career track before doing the management turnaround. How's it been? Bumpy, but fun. In this article, I'll share the things I love and hate about my current job. Love Let's start with the positive side of management positions. There's plenty to love, honestly. Impact First things first, I adore the power to improve the product we're building, and the overall team well-being that comes with a management position. As an engineer, you'll sometimes find yourself in a tough spot with little to no power to change things. Early morning standups are a chore? Code quality sucks? The new feature makes no sense? As a manager, the power to change is yours: you get both the formal and informal authority to change things for the better, and to make yourself and your team happier. Your words have weight. If you, an IC, say "guys, we really should write tests", everybody goes "oh, crazy old Vladimir, all grumpy again, haha, where do you see tests fit here?". If you, an EM, casually say "guys, we really should write tests", you might be surprised to find the tests unexpectedly growing in different places. Pleasant. Career opportunities Being an engineering manager is a more promising career opportunity than an engineering track. This might be controversial, but hear me out: The EM is normally higher-paid than the basic team-level engineering grades (junior / middle / senior). There are higher IC grades (staff, principal, president of code, whatever) in the EM+ salary bands. These staff+ IC jobs are concentrated in larger tech companies, because those have tougher technical challenges. Almost every software team in every company has a leadership position. The management career ladder is "taller" than that of ICs. Yes, the chances of becoming a CTO are slim, but it's an opportunity that's just not there for a pure IC with no management experience. All in all, I believe the demand for EMs to be steadier than for staff+ engineers, and this path gives you more opportunities at the later stages of your career. On a related note... Transferable skills Management skills are more widely useful than an IC engineering role. A decent front-end engineer with React experience won't have trouble moving to another front-end framework, and can probably transition to a back-end / mobile engineering role with -1 grade (a year handicap or so). That's not bad. What roles are available to someone with engineering management experience? First, you can easily take on a team with a wildly different focus — mobile developers, infrastructure, ML engineers. You'd need some time to get up to speed on the big-picture technical struggles of your new team, but most companies would take this shot. If you don't want to be an EM any more, you're well-positioned to move to a project or product management role. If the entire tech market falls into decline, many management skills would still work for other industries. While I don't see a big flow of tech managers moving into construction business (tech does pay well), there's one alternate path to consider — entrepreneurship. Involvement with people and business decisions makes for great training before starting your own business. So, being a manager gives you quite a bit of career flexibility, and makes you less vulnerable to future technological shifts. Less knowledge rot Suffering from front-end fatigue? Can't keep up with the newest shiniest frameworks and tools? Management's got you covered! The "hot new" agile / kanban / scrum methodologies are 20–30 years old. The basic meeting types (demos, dailies, 1-on-1s) have been developing for centuries. At the core, you have teamwork and human interactions, which haven't changed that much since the beginning of humanity. My grandfather was a big railroad boss in the 70s, and we can sensibly discuss some of my work challenges. "Oh, you have this talented slacker? Give him some big important task, let's see what he's worth." When it comes to computers, he's more like "I'd like a shovel big enough to throw all your silly gadgets into stratosphere." So, if you're tired of keeping up with the latest hot thing in tech, a management role can provide a well-deserved relief. Do keep an eye on what's happening on the tech side of things, but there's no urgency, and no need to get real deep. New challenges Frankly, after 4–5 years of working in a particular tech area, you can solve the vast majority of practical problems well enough. If you want some work challenge, you can: Slightly alter your stack — say, a new FE framework. But it's unlikely to keep you engaged very long. Make a broader career shift — e.g. frontend to backend. This would probably give you another couple years of fun, but such transitions are, in my experience, either random (e.g. your BE dev quits and someone has to fill the role), or hit your salary. Invent problems out of thin air — rewrite everything using a new library, or handle 9000 RPS "for the future". Fun, but most of the time it's more harm than good for your team and business. Of all the possible career moves a seasoned engineer can make, switching to management gives you the most new challenges (years worth of new stuff to learn) without hitting your salary. Hate As much as I like the challenges and impact of my new role, and the practical career benefits, I'll be the first one to admit it has downsides as well. Corporate BS As an engineer, I hated bloody corporate BS: individual performance reviews, useless deadlines, company-enforced restrictions on processes and tech stack. Well, congratulations, as a manager you are the sheriff of these practices, whether you believe in them or not. As a leader of a team in an org with performance calibrations, I must nominate 1 person who hasn't been working hard enough every 6 months. This human chess is soul-sucking, but I can't make it go away — if I don't offer a sacrificial teammate, someone will be picked randomly further down the process. Crazy shit. Sometimes you can negotiate a bit, or hack the process, e.g. assign "below-expected performance" on a round-robin basis, but to your team you'll sometimes be the corporate monster. Sigh. And I haven't even been through the real tough stuff like layoffs, closures and reorganizations. Awkward social situations I've made it to an engineering management position by being good at building stuff. I've been prepared to help with technical decisions, give career guidance, tune processes and set up automation as needed. In fact, a large portion of my job is debugging social tensions and psychological insecurities of people. Your junior engineer comments out a few tests to deploy a feature preview. The QA person sees this, and is very pissed because your whole team apparently does not respect the QA role and the value they provide. Restore trust. A project manager makes an unsuccessful joke that hurts your designer, who's now crying. Make the PM apologize. Am I a kindergarten teacher or something? Boy, I'm no psychologist, and I can't say I'm exceptionally good with people. This part of my job is quite hard, trying to fake it til I make it here. Office hours Life of an engineer is relatively relaxed. If you don't have anything urgent, you can go lay on the grass for half a day, thinking about the future of your project or something. You can miss a few meetings on short notice, no questions asked. Now, you're an EM. Try going and lying on the grass for a few hours. You come back to a messenger full of problems: your intern can't work because she forgot how to npm install; a senior manager wants to discuss some potential feature; release has derailed. Also, you can't really skip a meeting you're supposed to facilitate / organize without some up-front preparation. This might improve as your team matures and builds better processes, but in general you feel office hours much more as a manager, and your work-life balance directly depends on how good you are at your job. Long feedback loop The final thing I hate about management is the long feedback loop of your actions. Most engineering tasks show the result quite fast: new features take weeks to months, and if that's too long for you — fix a bug and see happy users the next day, or refactor some code and watch complexity decrease in a few hours. Amazing! You're a manager? Well, very few of your actions produce a visible result in under a month. Suppose your team has grown too large, and you want to split it up. You must pick a well-rounded set of engineers for the new team, talk to everybody involved to see how they feel about such a change, arrange new regular meetings, set up processes and communications, do some jira magic, maybe isolate the codebases of sub-products. If you think it can be done in a week, well, you're wrong. Then, even the right changes can make things get worse before they get better. Say you're understaffed, and you decide to hire. In the short term, you spend hours and hours interviewing, and a new team member won't get up to speed right away, sucking out precious time for onboarding. It's sometimes hard to see the long-term goal behind the short-term inconvenience. So, while engineering problem-solving is often fairly straightforward, management changes are more similar to large-scale refactorings. You won't see any quick improvements, which can be frustrating. To sum up, moving from an IC engineering role to a management position has been a rollercoaster ride for me, with both bright and bleak spots. Here's what I love: The wider impact on the product and team. Management is a great long-term career track: it gives you more job opportunities than a staff+ IC, the flexibility to move between different technical areas and roles, and skills that will be relevant across various industries for years to come. If you're bored with your field of tech expertise, moving to a management role is a great way to bring the challenge back into your job. And here's what I hate: Enforcing corporate decisions and policies can be soul-sucking. Dealing with social tensions and psychological insecurities of people isn't something I was ready for. It's hard to go offline even for a few hours without preparing in advance. Your actions have long and non-linear feedback loops with very delayed gratification. Now, is this career move the right one for you? If you enjoy challenge and responsibility, and you get an opportunity — I'd say go for it! Yes, management is not a fit for everybody (I'm not even sure it fits me TBH), but it's a great experience that would surely expand your skill set and make you see engineering work from a new angle. If you totally hate it, you have plenty of time to go back into coding =)
Aspiring developers often ask me what's the best programming language to learn. Personally, I mostly work with JS — solid choice, but everyone and their dog learns JS these days, so it might be time to add some diversity. I'm curious — which single programming language covers the most bases for you, and gives you most career opportunities for years to come? That's the question we'll try to answer today. Here's the plan. I made a list of 8 tech specializations: 2 web development areas: back- and front-end. Both pretty big areas, and ones I have most experience with. Mobile and desktop native app development. Native app development (especially desktop apps) seems to have fallen out of favor, but there's still enough work in these areas. Quality assurance automation. QA grows along with engineering, and increasingly relies on automated tests. Embedded systems. We'll focus on microcontroller programming, not fat boxes with a full windows / linux OS. Quite a promising area with the growth of IoT. Game development. Granted, I don't know much about this area, but I'll do my best to cover it as well, as many developers dream of building a fun game someday. Data analysis and Machine Learning. One of the most hyped areas of the last decade. The contenders are the usual suspects from TIOBE top 20: python, C, C++, Java (grouped with Kotlin and other JVM languages), C# (again, throw in VB and other .NET languages), JavaScript (and TypeScript), PHP, Go, Swift, Ruby, Rust. I left out SQL and Scratch, because they're not general-purpose languages, and Fortan with Matlab, because they aren't really used outside of scientific / engineering computing. A language scores 1 point by being the industry standard in the area — vast community and ecosystem, abundant jobs. Being useful for certain tasks in the area gets you 0.5 points. So, let's see what languages will make you the most versatile engineer, shall we? Backend Let's start with the simple one — Java, C#, Python, PHP, Go and Ruby are all excellent back-end programming languages. Of these, I'd say PHP is slightly more useful as many low-code solutions rely on it, and Ruby is steadily declining. Still, all these languages have earned 1 point. Next, 0.5 points go to: C++, used in high-load and time-critical scenarios, JS — node.js is often used to support front-end, but there aren't that many strictly back-end jobs for JS developers. Rust — still not that widely used, but growing fast. The only languages to fail here are Swift (technically usable on server via e.g. vapor, but I couldn't find any jobs in this stack) and C. Frontend Obviously, JavaScript is the language for front-end developers, which runs natively in browsers. But, surprise, other languages still qualify! All solid back-end languages (Java, C#, Python, PHP, Go, Ruby) get 0.5 points, because you can solve many UI problems by rendering HTML server-side the old-school way. C# has a slight edge here, since blazor is quite smart and popular. C, C++, and Rust score 0.5 points because they can be compiled to WebAssembly and run in the browser — just look at figma. Rust also powers some cool JS tooling, like biome and swc The only language to fail here is, again, Swift. QA automation The topic of QA automation is really simple. Java and python get the cake — Allure, Selenium, JUnit, and pytest are the most sought-after automation tools on the market right now. JS gets 0.5 points for playwright and cypress — the preferred tools for testing complex web front-ends. A few automation tools support C# — worth 0.2 points. Mobile apps Another straightforward area. Android apps are written in JVM languages (Java / Kotlin), iOS is integrated with Swift (finally). JS scores 0.5 points, because you can effectively build apps with React Native, and you can get pretty far with PWA or a good old WebView. Another 0.5 point for C#, thanks to Xamarin and MAUI. Desktop apps (windows / linux / MacOS) The three kings here are C++, C#, and Java. JS gets 0.5 points, again, for electron — disgusting or not, it's widely used. Another 0.5 points for Swift, because that's what you build MacOS apps with, but MacOS computers are relatively niche. Rust has the highly-hyped Tauri project for building desktop apps, but it's not that widespread, and I'm not aware of any high-profile apps using it. Let's give each 0.2 points for the effort and check back later. Embedded systems Embedded systems are usually tight on resources, so compiled languages are the way to go here. Basically any embedded job requires C and C++. Rust is, as usual, very promising, but not that popular yet, so 0.5 points. Another half-point for Python — used for edge computer vision and prototyping, but struggling with high memory requirements. Game development The primary languages in big gamedev are C++ (used in Unreal Engine) and C# (for Unity). Since mobile games are a thing, Java and Swift get 0.5 points each, because that's what you'll likely use here. Another 0.5 points for JS (browser games). Rust should be quite a good fit for games, but (as expected by now) it's not quite there yet. Data Analysis & Machine Learning It's no secret that Python is the language of choice for anything data-related, and most of the cutting edge stuff happens, well deserved 1 point here. But do you know there's another top language to get your piece of Data & ML hype? Big companies have a lot of data, right? And big companies love Java. So, many big data tools (especially coming from Apache — Hadoop, Spark, Jena) work with Java, and most data jobs require experience with python or java, so another 1 point for java. On to more surprises. Large chunks of data-heavy python libraries are actually written in C / C++ — e.g. over a third of numpy, or most of LlamaCPP — which earns both half-a-point. As you'd expect, Rust is also gaining traction for this use case with stuff like pola.rs, so another 0.2 points! The final half-a-point goes to JS for powering much of the UI / visualization stuff (see e.g. bokeh). Before we reveal our final ranking, let's weigh the categories, because they're not the same size. I've used some back-of-the-napkin analysis of job postings and sizing of reddit / linkedin groups and my personal experience. With backend as our reference, I'd say frontend is roughly the same size. Mobile development is surprisingly sizable — let's give it a 0.6 weight. For QA, I'd say 0.2 makes sense, as 1 QA per 3–5 devs is a normal ratio, and manual QA is still a thing. Desktop is easily the smallest area, looks like a 0.1 to me. For gamedev, 0.5 is just my random guess. Finally, there are surprisingly many data people — with the good salaries, let's make it a 0.6. Putting it all together: Java takes the first spot by a good margin by topping 5 categories, and having some gamedev / frontend capabilities. Place other JVM languages (especially Kotlin) around here, but with a discount since they're not as widely used. The next three are really close, but JS gets slighly ahead by being average at everything except embedded, even though it's only the top choice for front-end development. Python and C# tie for the third place. Both are top-tier backend languages with other strong areas (QA / ML for python, desktop and gamedev for C#). C++ is not that far behind either, as it's still the top language when it comes to efficiency. It also steps into other languages' realms when they need some speedup (WebAssembly / ML). Next come "three backend friends" — Go, PHP, and Ruby. All top-notch languages for building web backends, but not much else beyond that. Of these, Ruby is on the decline, and PHP and Go both have their separate niches. Rust does not score that well, but still makes it into the top 10 — not bad for such a new language. It has great growth potential by eating at the traditional C++ areas, super excited to see where it gets in 3–5 years. We all love good old C, but C++ looks like a better fit for complex systems. Swift comes in last — fair enough for a language that's only useful for the products of one single company. Perhaps surprisingly, the single most useful language is Java. Python and JS, beginner favorites, come strong, with a very different focus. C# perhaps deserves a bit more attention. Overall, today we've learnt about many amazing technologies that allow languages to sneak into each other's territory. If you were to start anew, what language would you learn?
It's hard to believe, but, starting mid-october 2023 I conducted 60 technical interviews and hired 10 people into our team. It's been extremely tiring: around 80 hours of active interviewing, plus writing interview reports, plus screening CVs and take-home assignments, plus onboarding new members — all while doing my normal work stuff. Still, I feel like I learnt a lot in the process — things that would help me as a candidate in the future, and might help you land your next job. Note that I'm a fairly relaxed interviewer, and, as an internal startup of a large tech company, we generally have a more humane hiring process, so your mileage may vary. Still, I've done my best to pick the tips that I feel are universally applicable. Here are nine insights I took out of this experience, in no particular order: Be generous with your "expected income". Say you're a solid higher-middle engineer, and you ask for a senior salary. My thought process: OK buddy, it's a bit more than reasonable now, but I won't have to fight for your promotion 8–12 months from now when you get there, and I don't have to spend another 12 hours of my own time (and leave my team understaffed for another few weeks) looking for a real hardcore senior, so I'll let you have it. Now suppose you ask for a junior salary. It's suspicious — why is your bar so low? Is there someting about your work performance you're not telling us? So, do your research on reasonable salaries for your level of experience, and aim slightly above that. Ask the right questions. I always leave time for the candidate to ask me questions — obviously, this lets the candidate probe what it's like to work at our team, but it's also the best opportunity for me to learn what really matters to the candidate. I've never been much of an asker myself, but now I see that "Thanks, I have no questions" does not look good — if anything, it paints you as someone who doesn't care. Here's a short list of good questions: What does the daily work in this role look like? Harmless. What features are you building next? Caring about the overall product, nice. Sometimes the answer is "I can't disclose this secret", but not that often. Anyting about processes or team structure: how many people are on the team? How often do you release? What regular meetings do you have? Interested in organization, might want to be a team lead someday, great. Anything tech-related: which framework do you use? Why did you pick framework X? How do you test your app? Especially suitable for junior- to middle developers who are most involved in hands-on work. What kind of tasks do you see me doing? Again, just a good neutral question, because responsibilities for any role differ wildly between companies. What growth / promotion opportunities does this position have? Cool trick, flipping the feared "where do you see yourself in 5 years" question against the hiring manager. Here are a few questions that are not very good: Do you use jira and github? It's a minor detail, won't you be able to work with youtrack and gitlab? Do you sometimes work late? Only if something breaks, but overall this question makes you seem a bit lazy. People on poor teams that routinely overtime aren't likely to answer this question honestly, at any rate. Social skills matter. I understand that not everybody is super outgoing, but if we already feel awkward 1 hour into our acquaintance, why work together — to feel awkward for months to come? Just a few tips anyone can follow: Be energetic. You're tired, I'm tired, we're all tired of endless interviews. Are you just tired today, or generally always too tired to get anything done? I know it's easier said than done, but try and show me all the energy you have left. Show respect. People enjoy being respected. Very easy one: you have a great product. Sounds like you have a great engineering culture. This is one of the most interesting interviews I've ever seen. Like, I know you don't necessarily mean that, but subconsciously I'm very pleased: "oh yes, I'm very proud of my interview process, thanks for noticing" On a related note... Provide conversation opportunities. Q: Do you use TDD? Bad answer: "no". Good answer: "no, but I've heard of it. Interesting approach. Does your team use TDD?" Now you get to spend 5 minutes talking on your terms instead of being bombarded with random questions, and you come off as someone curious about stuff. On another related note... It's easy to hurt people. People normally ask you about stuff because they care about it. So, again, the interviewer askning "do you use TDD?", presumably, likes TDD and uses it. So, the worst answer: "no, TDD sucks, it's pure waste of time for idiots." A rare interviewer might appreciate you having a strong opinion on a topic, but to most this just paints you as a jerk, kinda like "Here's a photo of my children — "I hate children, and yours are especialy horrible". Not smart. Smart talk is not your friend. Saying stuff like "our front-end guild evaluated several cutting-edge approaches to testing universal applications" only makes you seem smart if you can elaborate on that topic: what these approaches were, the pros and cons you found, what tradeoffs you made for your final decision. If you can't answer a follow-up question beside "we settled on jest, not sure why", it was better to stay away from that topic altogether. Related: "in code reviews, I always consider the optimality of the algorithm selected" (proceeds to estimate the time complexity of comparison-based sorting as O(1). I never ask this unless the candidate boasts about her algo skillz). Admit your mistakes. Don't know an answer? Your code has a bug? It's always better to admit it and then try to come up with something at the spot than trying to talk your way out of it. Event loop? Sure thing, I'm an expert on loops. It's the way events are looped. Uses logarithmic weighing. Again, this makes you look like a candidate with big mouth and small hands. I have seen a couple of people who could talk their way out of any situation, but I honestly think with such skills you'd do better in a different line of work, like international relations, or selling financial services. Note that you really should give it your best shot — giving up at the first sign of trouble is not a good impression. If you genuinely have no idea — see conversation opportunity: "Event delegation? Tough luck, never heard of it. Would you tell me about it so that I learn something new today?" Make yourself memorable. It's hard to keep detailed profiles of 10 candidates in mind — after a good interview streak all I remember is the general impression (great / OK / horrible) and a few truly notable things. This guy worked for some crypto scam that went bust, that girl had a cute dog that was trying to eat the camera. The worst you can do is be a totally neutral candidate — we've had an interview, but I can't remember any details. So try and sneak some anecdote, or wear a silly scarf — something to remember. This point is especially important for intern / junior positions — online JS bootcamps do a good job of covering the basics, and it's really hard to differentiate these candidates. The memorable thing doesn't have to be professional, or even positive (even though it sure won't hurt) — your best bet would be some original personal project. Ask for feedback on the spot. Asking how you did at the end of the interview doesn't hurt. Yes, some interviewers will be hesitant to answer — at large companies, the feedback is normally sent through the recruiter, and you're never sure if sidestepping this process would get you into trouble. Besides, if the feedback is not complimentary, you're essentially asking for conflict at the spot, and people normally avoid conflict when possible. Still, it's a chance to adjust your expectations (if the interviewer says, looking you in the eyes, that you've done great, it's a good sign), and you might get actually useful tips that would probably get lost passing through the written report, and then through the non-technical recruiter.
We've already learnt a lot about svelte's reactivity system — the primary way to work with state in svelte components. But not all state belongs in components — sometimes we want app-global state (think state manager), sometimes we just want to reuse logic between components. React has hooks, Vue has composables. For svelte, the problem is even harder — reactive state only works inside component files, so the rest is handled by a completely separate mechanism — stores. The tutorial does a decent job of covering the common use cases, but I still had questions: What's the relationship between the stores? Are they built on some common base? Is it safe to use { set } = store as a free function? How does get(store) receive the current value if it's not exposed on the object? Does set() trigger subscribers when setting the current value? What's the order of subscriber calls if you set() inside a subscriber? Does derived listen to the base stores when it's not observed? Will changing two dervied dependencies trigger one or two derived computations? Why does subscribe() have a second argument? What is $store sytax compiled to? In this article, I explore all these questions (and find a few svelte bugs in the process). writable is the mother store Svelte has 3 built-in store types: writable, readable, and derived. However, they are neatly implemented in terms of one another, taking only 236 lines, over half of which is TS types and comments. The implementation of readable is remarkably simple — it creates a writable, and only returns its subscribe method. Let me show it in its entirety: const readable = (value, start) => ({ subscribe: writable(value, start).subscribe }); Moreover, derived is just a special way of constructing readable: export function derived(stores, fn, initial_value) { // ...some normalization return readable(initial_value, /* some complex code */); } While we're at it, note that update method of a writable store is a very thin wrapper over set: fn => set(fn(value)). All in all: writable is the OG store, readable just removes set & update methods from a writable, derived is just a predefined readable setup, update is just a wrapper over set. This greatly simplifies our analysis — we can just investigate writable arguments, subscribe, and set — and our findings also hold for other store types. Well done, svelte! Store methods don't rely on this Writable (and, by extension, readable and derived) is implemented with objects and closures, and does not rely on this, so you can safely pass free methods around without dancing with bind: const { subscribe, set } = writable(false); const toggle = { subscribe, activate: () => set(true) }; However, arbitrary custom stores are not guaranteed to have this trait, so it's best to stay safe working with an unknown store-shaped argument — like svelte itself does with readonly: function readonly(store) { return { subscribe: store.subscribe.bind(store), }; } Subscriber is invoked immediately As svelte stores implement observable value pattern, you'd expect them to have a way to access current value via store.get() or store.value — but it's not there! Instead, you use the special get() helper function: import { get } from 'svelte/store' const value = get(store); But, if the store does not expose a value, how can get(store) synchronously access it? Normally, the subscribers are only called on change, which can occur whenever. Well, svelte subscribe is not your average subscribe — calling subscribe(fn) not only starts listening to changes, but also synchronously calls fn with the current value. get subscribes to the store, extracts the value from this immediate invocation, and immediately unsubscribes — like this: let value; const unsub = store.subscribe(v => value = v); unsub(); The official svelte tutorial section on custom stores says: as long as an object correctly implements the subscribe method, it's a store. This might bait you into writing "custom stores" with subscribe method, not based off of writable. The trick word here is correctly implements — even based on the tricky subscribe self-invocation it's not an easy feat, so please stick to manipulations with readable / writable / derived. set() is pure for primitives writable stores are pure in the same sense as svelte state — notifications are skipped when state is primitive, and the next value is equal to the current one: const s = writable(9); // logs 9 because immediate self-invocation s.subscribe(console.log); // does not log s.set(9); Object state disables this optimization — you can pass a shallow equal object, or the same (by reference) object, the subscribers will be called in any case: const s = writable({ value: 9 }); s.subscribe(console.log); // each one logs s.update(s => s); s.set(get(s)); s.set({ value: 9 }); On the bright side, you can mutate the state in update, and it works: s.update(s => { s.value += 1; return s }); Subscriber consistency Normally, store.set(value) synchronously calls all subscribers with value. However, a naive implementation will shoot you in the foot when updating a store from within a subscriber (if you think it's a wild corner case — it's not, it's how derived stores work): let currentValue = null; const store = naiveWritable(1); store.subscribe(v => { // let's try to avoid 0 if (v === 0) store.set(1); }) store.subscribe(v => currentValue = v); If we now call set(0), we intuitively expect both the store's internal value and currentValue to be 1 after all callbacks settle. But in practice it can fail: Store value becomes 0; First subscriber sees 0, calls set(1), then: Store value becomes 1; set(1) synchronously invokes all subscribers with 1; First subscriber sees 1, does nothing; Second subscriber is called with 1, sets currentValue to 1; First subscriber run for 0 is completed, continuing with the initial updates triggered by set(0) Second subscriber is called with 0, setting currentValue to 0; Bang, inconsistent state! This is very dangerous territory — you're bound to either skip some values, get out-of-order updates, or have subscribers called with different values. Rich Harris has taken a lot of effort to provide the following guarantees, regardless of where you set the value: Every subscriber always runs for every set() call (corrected for primitive purity). Subscribers for one set() run, uninterrupted, after one another (in insertion order, but I wouldn't rely on this too much). Subscribers are invoked globally (across all svelte stores) in the same order as set calls, even when set calls are nested (called from within a subscriber). All subscribers are called synchronously within the outermost set call (the one outside any subscriber). So, in our example, the actual callback order is: subscriber 1 sees 0, calls set(1) subscribers calls with 1 are enqueued subscriber 2 sets currentValue = 0 subscriber 1 runs with 1, does nothing subscriber 2 sets currentValue = 1 Since the callback queue is global, this holds even when updating store B from a subscriber to store A. One more reason to stick with svelte built-in stores instead of rolling your own. Derived is lazy derived looks simple on the surface — I thought it just subscribes to all the stores passed, and keeps an up-to-date result of the mapper function. In reality, it's smarter than that — subscription and unsubscription happens in the start / stop handler, which yields some nice properties: Subscriptions to base stores are automatically removed once you stop listening to the derived store, no leaks. Derived value and subscriptions are reused no matter how many times you subscribe to a derived store. When nobody is actively listening to a derived store, the mapper does not run. The value is automatically updated when someone first subscribes to the derived store (again, courtesy of subscribe self-invocation). Very, very tastefully done. Derived is not transactional While lazy, derived is not transactional, and not batched — synchronously changing 2 dependencies will trigger 2 derivations, and 2 subscriber calls — one after the first update, and one after the second one. In this code sample, we'd expect left + right to always be 200 (we synchronously move 10 from left to right), there's a glimpse of 190 (remember, the subscribers are synchronously called during set): const left = writable(100); const right = writable(100); const total = derived([left, right], ([x, y]) => { console.log('derive', x, y); return x + y; }); total.subscribe(t => console.log('total', t)); const update = () => { // try to preserve total = 200 left.update(l => l - 10); // ^^ derives, and logs "total 190" right.update(r => r + 10); // ^^ derives, and logs "total 200" }; This isn't a deal breaker, svelte won't render the intermediate state, but it's something to keep in mind, or you get hurt: const obj = writable({ me: { total: 0 } }); const key = writable('me'); const value = derived([obj, key], ([obj, key]) => obj[key].total); // throws, because { me: ... } has no 'order' field key.set('order'); obj.set({ order: { total: 100 } }); The mysteryous subscriber-invalidator Looking at subscribe() types, you may've noticed the mysterious second argument — invalidate callback. Unlike the subscriber, it's not queued, and is always called synchronously during set(). The only place I've seen an invalidator used in svelte codebase is inside derived — and, TBH, I don't understand its purpose. I expected it to stabilize derived chains, but it's not working. Also, the TS types are wrong — the value is never passed to invalidator as an argument. Verdict: avoid. $-dereference internals As you probably know, svelte components have a special syntax sugar for accessing stores — just prefix the store name with a $, and you can read and even assign it like a regular reactive variable — very convenient: import { writable } from 'svelte/store'; const value = writable(0); const add = () => $value += 1; <button on:click={add}> {$value} </button> I always thought that $value is compiled to get, $value = v to value.set(v), and so on, with a subscriber triggering a re-render in some smart way, but it's not the case. Instead, $value becomes a regular svelte reactive variable, synchronized to the store, and the rest is handled by the standard svelte update mechanism. Here's the compilation result: // the materialized $-variable let $value; // the store const value = writable(0); // auto-subscription const unsub = value.subscribe(value, value => { $$invalidate(0, $value = value) }); onDestroy(unsub); const add = () => { // assign to variable $value += 1; // update store value.set($value); }; In plain English: $store is a real actual svelte reactive variable. store.subscribe updates the variable and triggers re-render. The unsubscriber is stored and called onDestroy. AFAIK, store.update is never used by svelte. Assignments to $store simultaneously mutate $store variable without invalidating and triggering re-render and call store.set, which in turn enqueues the update via $$invalidate The last point puts us in a double-source-of-truth situation: the current store value lives both in the $store reactive variable, and inside store itself. I expected this to cause some havok in an edge case, and so it does — if you patch store.set method to skip some updates, the $-variable updates before your custom set runs, and the two values go out of sync as of svelte@3.59.1: const value = { ...writable(0), // prevent updates set: () => {} }; const add = () => $value += 1; let rerender = {}; $: total = $value + (rerender ? 0 : 1); {total} <button on:click={add}>increment</button> <button on:click={() => rerender = {}}> rerender </button> To summarize: Both readable and derived are built on top of writable — readable only picks subscribe method, derived is a readable with a smart start / stop notifier. Built-in stores don't rely on this, so you can safely use their methods as free functions. Calling subscribe(fn) immediately invokes fn with the current value — used in get(store) to get the current value. Calling set() with the current value of the store will skip notifying subscribers if the value is primitive. set() on object state always notifies, even if the object is same, by reference, as the current state. The subscribers for a single set() run after one another. If a subscriber calls set, this update will be processed once the first set() is fully flushed. derived only subscribes to the base stores and maps the value when someone's actively listening to it. When synchronously changing two dependencies of derived, the mapper will be called after the first change. There's no way to batch these updates. subscribe() has a second argument — a callback that's called synchronously during set(). I can't imagine a use case for it. $store syntax generates a regular svelte reactive variable called $store, and synchronizes it with the store in a subscriber. If you learn one thing from this article — svelte stores are thoughtfully done and help you with quite a few corner-cases. Please avoid excessive trickery, and build on top of the svelte primitives. In the next part of my svelte series, I'll show you some neat tricks with stores — stay tuned on twitter!
More in programming
As search gets worse and “working code” gets cheaper, apps get easier to make from scratch than to find.
I’ve never published an essay quite like this. I’ve written about my life before, reams of stuff actually, because that’s how I process what I think, but never for public consumption. I’ve been pushing myself to write more lately because my co-authors and I have a whole fucking book to write between now and October. […]
Less known desktop UI frameworks Writing desktop software is hard. The UI technologies of Windows or MacOS are awful compared to web technology. What can trivially be done with HTML/CSS/JavaScript in few minutes can take hours using Windows’s win32 APIs or Mac’s Cocoa. That’s why the default technology for desktop apps, especially cross-platform, is Electron: a Chrome browser combined with Node runtime. The problem is that it’s bloaty: each app is a unique build of Chrome with a little bit of application code. Chrome is over 100MB so many apps ship less than 1MB of code in a 100M wrapper. People tried to address the problem of poor OS APIs by writing UI frameworks, often meant to be cross-platform. You’ve heard about QT, GTK, wxWindows. The problem with those is that they are also old, their APIs are not the greatest either and they are bloaty as well. There just doesn’t seem to be a good option. Writing your own framework seems impossible due to the size of task. But is it? I’ll show a couple of less-known UI frameworks written mostly be a single person, often done simply to enable writing an application. SWELL in WDL WDL is interesting. Justin Frankel, the guy who created Winamp, has a repository of C++ code he uses in different projects. After selling Winamp to AOL, a side quest of writing file sharing application, getting fired from AOL for writing file sharing application, he started a company building Reaper a digital audio workstation software for Windows. Winamp is a win32 API program and so is Reaper. At some point Justin decided to make a Mac version but by then he had a lot of code heavily using win32 APIs. So he did what anyone in his position would: he implemented win32 APIs for Mac OS and Linux and called it SWELL - Simple Windows Emulation Layer. Ok, actually no-one else would do it. It was an insane idea but it worked. It’s important to not over-state SWELL capabilities. It’s not Wine. You can’t take any win32 program and recompile for Mac with SWELL. Frankel is insanely pragmatic and so is his code. SWELL only implements the subset of APIs he uses in Reaper. At the same time Reaper is a big app so if SWELL works for Reaper, it could work for your app. WDL is open-source using permissive MIT license. Sublime Text For a few years Sublime Text was THE programmer’s editor. It was written by a single developer in C++ and he wrote a custom UI toolkit for it. Not open source but its existence shows it can be done. RAD Debugger RAD Debugger is an open-source Windows debugger for C/C++ apps written in C by mostly a single person. It implements a custom UI framework based on 3D renderer. The UI is integral part of the the app but the code is well structured so you probably can take just their UI / render code and use it in your own C / C++ app. Currently the app / UI is only for Windows but it’s designed to be cross-platform and they are working on porting the renderer to Mac OS / Linux. They use permissive MIT license and everything is written in C. Dear ImGUI Dear ImGui is a newer cross-platform, UI framework in C++. Open source, permissive MIT license. Written by mostly a single person. Ghostty Ghostty is a cross-platform terminal emulator and UI. It’s written in Zig by mostly a single person and uses it’s own low-level GPU renderer for the UI. You too can write your own UI framework At first the idea of writing your own UI framework seems impossibly daunting. What I’m hoping to show is that if you’re ambitious enough it’s possible to build cross platform desktop apps that are not just bloated 100MB Chrome wrappers around few kilobytes of custom code. I’m not saying it’s a simple thing, just that enough people did it that it’s possible. It shouldn’t be necessary but both Microsoft and Apple have tragically dropped the ball on providing decent, high-performance UI libraries for their OS. Microsoft even writes their own apps, like Teams, in web technologies. Thanks to open source you’re not at the staring line. You can just use Dear ImGUI or WDL’s SWELL. Or you can extract the UI code from RAD Debugger or Ghostty (if you write in Zig). Or you can look at how their implementation to speed up your own design and implementation.
I released Logic for Programmers exactly one year ago today. It feels weird to celebrate the anniversary of something that isn't 1.0 yet, but software projects have a proud tradition of celebrating a dozen anniversaries before 1.0. I wanted to share about what's changed in the past year and the work for the next six+ months. The Road to 0.1 I had been noodling on the idea of a logic book since the pandemic. The first time I wrote about it on the newsletter was in 2021! Then I said that it would be done by June and would be "under 50 pages". The idea was to cover logic as a "soft skill" that helped you think about things like requirements and stuff. That version sucked. If you want to see how much it sucked, I put it up on Patreon. Then I slept on the next draft for three years. Then in 2024 a lot of business fell through and I had a lot of free time, so with the help of Saul Pwanson I rewrote the book. This time I emphasized breadth over depth, trying to cover a lot more techniques. I also decided to self-publish it instead of pitching it to a publisher. Not going the traditional route would mean I would be responsible for paying for editing, advertising, graphic design etc, but I hoped that would be compensated by much higher royalties. It also meant I could release the book in early access and use early sales to fund further improvements. So I wrote up a draft in Sphinx, compiled it to LaTeX, and uploaded the PDF to leanpub. That was in June 2024. Since then I kept to a monthly cadence of updates, missing once in November (short-notice contract) and once last month (Systems Distributed). The book's now on v0.10. What's changed? A LOT v0.1 was very obviously an alpha, and I have made a lot of improvements since then. For one, the book no longer looks like a Sphinx manual. Compare! Also, the content is very, very different. v0.1 was 19,000 words, v.10 is 31,000.1 This comes from new chapters on TLA+, constraint/SMT solving, logic programming, and major expansions to the existing chapters. Originally, "Simplifying Conditionals" was 600 words. Six hundred words! It almost fit in two pages! The chapter is now 2600 words, now covering condition lifting, quantifier manipulation, helper predicates, and set optimizations. All the other chapters have either gotten similar facelifts or are scheduled to get facelifts. The last big change is the addition of book assets. Originally you had to manually copy over all of the code to try it out, which is a problem when there are samples in eight distinct languages! Now there are ready-to-go examples for each chapter, with instructions on how to set up each programming environment. This is also nice because it gives me breaks from writing to code instead. How did the book do? Leanpub's all-time visualizations are terrible, so I'll just give the summary: 1180 copies sold, $18,241 in royalties. That's a lot of money for something that isn't fully out yet! By comparison, Practical TLA+ has made me less than half of that, despite selling over 5x as many books. Self-publishing was the right choice! In that time I've paid about $400 for the book cover (worth it) and maybe $800 in Leanpub's advertising service (probably not worth it). Right now that doesn't come close to making back the time investment, but I think it can get there post-release. I believe there's a lot more potential customers via marketing. I think post-release 10k copies sold is within reach. Where is the book going? The main content work is rewrites: many of the chapters have not meaningfully changed since 1.0, so I am going through and rewriting them from scratch. So far four of the ten chapters have been rewritten. My (admittedly ambitious) goal is to rewrite three of them by the end of this month and another three by the end of next. I also want to do final passes on the rewritten chapters; as most of them have a few TODOs left lying around. (Also somehow in starting this newsletter and publishing it I realized that one of the chapters might be better split into two chapters, so there could well-be a tenth technique in v0.11 or v0.12!) After that, I will pass it to a copy editor while I work on improving the layout, making images, and indexing. I want to have something worthy of printing on a dead tree by 1.0. In terms of timelines, I am very roughly estimating something like this: Summer: final big changes and rewrites Early Autumn: graphic design and copy editing Late Autumn: proofing, figuring out printing stuff Winter: final ebook and initial print releases of 1.0. (If you know a service that helps get self-published books "past the finish line", I'd love to hear about it! Preferably something that works for a fee, not part of royalties.) This timeline may be disrupted by official client work, like a new TLA+ contract or a conference invitation. Needless to say, I am incredibly excited to complete this book and share the final version with you all. This is a book I wished for years ago, a book I wrote because nobody else would. It fills a critical gap in software educational material, and someday soon I'll be able to put a copy on my bookshelf. It's exhilarating and terrifying and above all, satisfying. It's also 150 pages vs 50 pages, but admittedly this is partially because I made the book smaller with a larger font. ↩
Translating user interface of SumatraPDF SumatraPDF is the best PDF/eBook/Comic Book viewer for Windows. It’s small, fast, full of features, free and open-source. It became popular enough that it made sense to translate the UI for non-English users. Currently we support 72 languages. This article describes how I designed and implemented a translation system in SumatraPDF, a native win32 C++ Windows application. Hard things about translating the UI There are 2 hard things about translating an application code for translation system (extracting strings to translate, translate strings from English to user’s language) translating them into many languages Extracting strings to translate from source code Currently there are 381 strings in SumatraPDF subject to translation. It’s important that the system requires the least amount of effort when adding new strings to translate. Every string that needs to be translated is marked in .cpp or .h file with one of two macros: _TRA("Rename") _TRN("Open") I have a script that extracts those strings from source files. Mine is written in Go but it could just as well be Python or JavaScript. It’s a simple regex job. _TR stands for “translation”. _TRA(s) expands into const char* trans::GetTranslation(const char* str) function which returns str translated to current UI language. We auto-detect language at startup based on Windows settings and allow the user to explicitly set UI language. For English we just return the original string. If a string to be translated is e.g. a part of const char* array[], we can’t use trans::GetTranslation(). For cases like that we have _TRN() which expands to English string. We have to write code to translate it at some point. Adding new strings is therefore as simple as wrapping them in _TRA() or _TRN() macros. Translating strings into many languages Now that we’ve extracted strings to be translated, we need to translate them into 72 languages. SumatraPDF is a free, open-source program. I don’t have a budget to hire translators. I don’t have a budget, period. The only option was to get help from SumatraPDF users. It was vital to make it very easy for users to send me translations. I didn’t want to ask them, for example, to download some translation software. Design and implementation of AppTranslator web app I couldn’t find a really simple software for crowd sourcing translations so I wrote my own: https://github.com/kjk/apptranslator You can see it in action: https://www.apptranslator.org/app/SumatraPDF I designed it to be generic but I don’t think anyone else is using it. AppTranslator is simple. Per https://tools.arslexis.io/wc/: 4k lines of Go server code 451 lines of html code a single dependency: bootstrap CSS framework (the project is old) It’s simple because I don’t want to spend a lot of time writing translation software. It’s just a side project in service of the goal of translating SumatraPDF. Login is exclusively via GitHub. It doesn’t even use a database. Like in Redis, changes are stored as a series of operations in an append-only log. We keep the whole state in memory and re-create it from the log at startup. Main operation is translate a string from English to language X represented as [kOpTranslation, english string, language, translation, user who provided translation]. When user provides a translation in the web UI, we send an API call to the server which appends the translation operation to the log. Simple and reliable. Because the code is written in Go, it’s very fast and memory efficient. When running it uses mere megabytes of RAM. It can comfortably run on the smallest 256 MB VPS server. I backup the log to S3 so if the server ever fails, I can re-install the program on a new server and re-download the translations from S3. I provide RSS feed for each language so that people who provide translations can monitor for new strings to be translated. Sending strings for translation and receiving translations So I have a web app for collecting translations and a script that extracts strings to be translated from source code. How do they connect? AppTranslator has an API for submitting the current set of strings to be translated in the simplest possible format: a line for each string (I ensure there are no newlines in the string itself by escaping them with \n) API is password protected because only I can submit the strings. The server compares the strings sent with the current set and records a difference in the log. It also sends a response with translations. Again the simplest possible format: AppTranslator: SumatraPDF 651b739d7fa110911f25563c933f42b1d37590f8 :%s annotation. Ctrl+click to edit. am:%s մեկնաբանություն: Ctrl+քլիք՝ խմբագրելու համար: ar:ملاحظة %s. اضغط Ctrl للتحرير. az:Qeyd %s. Düzəliş etmək üçün Ctrl+düyməyə basın. As you can see: a string to translate is on a line starting with : is followed by translations of that strings in the format: ${lang}: ${translation} An optimization: 651b739d7fa110911f25563c933f42b1d37590f8 is a hash of this response. If I submit this hash with my request and translations didn’t change on the server, the response is empty. Implementing C++ part of translation system So now I have a text file with translation downloaded from the server. How do I get a translation in my C++ code? As with everything in SumatraPDF, I try to do things in a simple and efficient way. The whole Translation.cpp is only 239 lines of code. The core of translation system is const char* trans::GetTranslation(const char* s); function. I embed the translations in exact the same format as received from AppTranslator in the executable as data file in resources. If the UI language is English, we do nothing. trans::GetTranslation() returns its argument. When we switch the language, we load the translations from resources and build an index: an array of English strings an array of corresponding translations Both arrays use my own StrVec class optimized for storing an array of strings. To find a translation we scan the first array to find an index of the string and return translation from the second array, at the same index. Linear scan seems like it would be slow but it isn’t. Resizing dialogs I have a few dialogs defined in SumatraPDF.rc file. The problem with dialogs is that position of UI elements is fixed. A translated string will almost certainly have a different size than the English string which will mess up fixed layout. Thankfully someone wrote DialogSizer that smartly resizes dialogs and solves this problem. The evolution of a solution No AppTranslator My initial implementation was simpler. I didn’t yet have AppTranslator so I stored the strings in a text file in repository in the same format as what I described above. People would download it, make changes using a text editor and send me the file via email which I would then checkin. It worked for a while but it became worse over time. More strings, more languages created more work for me to manually manage e-mail submissions. I decided to automate the process. Code generation My first implementation of C++ side used code generation instead of embedding the text file in resources. My Go script would generate C++ source code files with static const char* [] arrays. This worked well but I decided to improve it further by making the code use the text file with translations embedded in the app. The main motivation for the change was to open a possibility of downloading latest translations from the server to fix the problem of translations not being all ready when I build the release executable. I haven’t done that yet but it’s now easier to implement given that the format of strings embedded in the exe is the same as the one I can download from AppTranslator. Only utf-8 SumatraPDF started by using both WCHAR* Unicode strings and char* utf8 strings. For that reason the translation system had to support returning translation in both WCHAR* and char* version. Over time I refactored the code to use mostly utf8 and at some point I no longer needed to support WCHAR* version. That made the code even smaller and reduced memory usage. The experience I’m happy how things turned out. AppTranslator proved to be reliable and hassle free. It runs for many years now and collected 35440 string translations from users. I automated everything so that all I need to do is to periodically re-run the script that extracts strings from source code, uploads them to AppTranslator and downloads latest translations. One problem is that translations are not always ready in time for release so I make a release and then people start translating strings added since last release. I’ve considered downloading the latest translations from the server, in addition to embedding them in an executable at the time of building the app. Would I do the same today? While AppTranslator is reliable and doesn’t require on-going work, it would be better to not have to run a server at all. The world has changed since I started SumatraPDF. Namely: people are comfortable using GitHub and you can edit files directly in GitHub UI. It’s not a great experience but it works. One option would be to generate a translation text file for each language, in this format: :first untranslated string :second untranslated string :first translated string translation of first string :second translated string translation of second string Untranslated strings are listed at the top, to make it easier to find. A link would send a translator directly to edit this file in GitHub UI. When translator saves translations, it creates a PR for me to review and merge. The roads not taken But why did you re-invent everything? You should do X instead. All other X that I know about suck. Using per-language .rc resource files Traditional way of localizing / translating Window GUI apps is to store all strings and dialog definitions in an .rc file. Each language gets its own .rc file (or files) and the program picks the right resource based on a language. This doesn’t solve the 2 hard problems: having an easy way to add strings for translations having an easy way for users to provide translations XML horror show There was a dark time when the world was under the iron grip of XML fanaticism. Everything had to be an XML file even when it was the worst possible solution for the problem. XML doesn’t solve the 2 hard problems and a string storage format is an absolute nightmare for human editing. GNU gettext There’s a C library gettext that uses .po files. This is much saner solution than XML horror show. .po files are relatively simple text format. The code is already written. Warning: tooting my own horn. My format is better. It’s easier for people to edit, it’s easier to write code to parse it. This looks like many times more than 239 lines of code. Ok, gettext probably does a bit more than my code, but clearly nothing than I need. It also doesn’t solve the 2 hard problems. I would still have to write code to extract strings from source code and build a way to allow users to translate them easily.