Balint Erdi

Dive into other people's code

Being able to read other people's code is a force multiplier for becoming a stellar software developer. When using open-source software, you'll undoubtedly need to examine code someone else wrote to better understand it. Many times, you get to that point when you're debugging

Be curious about your craft

"Be interested" sounds like telling you to fall in love with a particular person. I'll grant you it's similar, but being curious about the aspects of software development is much simpler. Which is great because it's essential for your career as a

Write it down - use notes to keep a second brain

There is only so much stuff you can keep in your brain. Sometimes, when I'm keeping track of all the information needed to understand a certain problem, I run out of memory. My FIFO*-based brain throws out the first piece of information to make space for the

Avoid distractions - and focus intensely

It's a cliché, but it's a cliché for a reason: if you want to solve challenging problems, you need to focus for an extended period. The fiercest enemy of sustained attention is our devices. They are all connected to the internet and are inexhaustible sources of

Get a quick win

We have a tough time starting but just as hard a time not finishing what we've started, especially if we have had even a tiny bit of success. You'll eventually lose motivation when you've set out to do something that takes a long time.

How I write articles

"How does Balint write these articles?" asked probably nobody, ever. So you didn't ask, and I still delivered. Below is my current method of writing. 1. Write a crappy first draft I put words down almost as they appear in my mind. As Stephen King says,

You can do it - just start

The saying "If you think you can win, or if you think you cannot, you're right" has a lot of truth to it. Staring at a computer screen with a daunting task ahead can feel overwhelming. You have to think about, code, fix, test, and refactor

Write a forum post

You can use a simple technique that gets you unstuck when you've been banging your head against the wall because of a problem you can't figure out. You tried everything to debug it, changing one thing at a time to see if it affected the outcome,

Setting up a TypeScript project

This year, I decided to learn TypeScript, or more precisely, to improve my very basic knowledge of the most popular flavor of JavaScript. I know some basic TS and I use ExecuteProgram to improve my knowledge each day but I believe that nothing makes you learn faster than building stuff

Just start over

I was on the cusp of finishing a complex component. The changes looked good locally so I pushed to CI, waiting for the green check mark and the immediate dopamine kick. Bang, a red cross. What the #!^^? Uncaught RangeError: Maximum call stack size exceeded the log read when running the

fail

[FAIL] Don't fix the same problem twice

And then it all made sense. The app uses band slugs (like "led-zeppelin") for ids, so the band_id was a string. In ruby, 'string'.to_i is 0, which is why all songs had a band_id of 0, and they didn't show up for any of the bands.

fail

[FAIL] VS Code auto-import breaking the build

I learned about the idea of being a señor engineer and publishing your fails during your work from Kenneth Larsen [https://www.kennethlarsen.org/] a few years ago. I really liked the idea but haven't had a single fail since then 😂 so you guys had to wait for