Wave is a $1.7B company with 70 engineers whose product is a CRUD app that adds and subtracts numbers. In keeping with this, our architecture is a standard CRUD app architecture, a Python monolith on top of Postgres. Starting with a simple architecture and solving problems in simple ways where possible has allowed us to scale to this size while engineers mostly focus on work that delivers value to users.

one of the best ways for programmers to get unstuck is to work on something else and come back later

The hardest thing is to leave the table with the problem unsolved, but always worth it

📢: Avoid Barrels

(A barrel is a file that exports code from other files)

Barrel benefits:
✅ Shorter import paths
✅ Support importing many files via one import
✅ "Hide" modules - Only export some modules for the "public" interface

But, I avoid barrels. Here's why:
🚫 Bloats the bundle. Inhibits tree shaking.
🚫 Increases memory usage.
🚫 Slows tooling (builds, tests, linting). Barrels create more modules to parse.
🚫 Slows code navigation ("Find all references" finds the barrel instead of the actual source).
🚫 Barrels shorten import paths and group related imports. Sounds nice, but it's an outdated benefit because I don't write imports anymore - my editor reliably auto-imports.

You are an individual contributor at heart. You like writing code and solving technical problems. You dislike meetings and ceremony. Here’s what you can do to maximize what you like and minimize what you don’t: radiate information.

I was looking for a tool for measuring metrics like LCOM in PHP. And... I've found @PhpStorm has a built-in list of "Refactoring opportunities" inspections which are turned-off by default :0.

If you want to turn them on, go to the Settings >Editor > Inspections.

Stripe subscriptions could be a real headache...

Here are the most important events to listen to grant/revoke access:

In October 1984 two ideologues published a radical manifesto… sort of. Program Design in the UNIX Environment, by comp-sci legends Brian Kernighan and Rob Pike, articulated a pattern for software architecture that both men had already spent years fighting to preserve.

Productivity is one of my pet topics, because it's always dogged me a bit, especially early in my career. I'd pull long days and nights and then realize I only actually worked (as in, typing in code, debugging stuff, and thinking about problems and their solutions) maybe 20% of the time. Upon talking to coworkers, this seemed to be normal, a part of the expected friction costs incurred working in an office environment. Meetings, shooting the shit with coworkers, lunch, email, and, er, stuff.

"Don't learn to code. Soon GUIs will do it all for you." - 1985

"Don't learn to code. Soon that will all be done offshore for pennies." - 2003

"Don't learn to code. Soon nocode tools will do it all for you." - 2015

"Don't learn to code. Soon AI will do it all for you." - 2023

truth developers don't want to accept:

• staging and production will never be identical

• production is unpredictable and all states cannot be captured by your testing suite

• problems that you really care about only happen in production

• testing in production works

GPT-4 just localized my entire app

GPT-4 strikes again. 🔥

I managed to automatize one of the most annoying things Laravel developers have to do.

Internationalizing a project by wrapping up strings in the __() helper across dozens of Blade templates.

What a relief! 😮‍💨

I'm working with a SPA that has a dedicated backend composed of over a dozen microservices.

Each service has its own repo, and its own DB, even though all services are built and maintained by one team.

I do not recommend this.

🚩Can't do atomic commits 🚩Lots of friction jumping between repos and DB's 🚩Hard to configure CI, or to manage cross-repo breaking changes 🚩Repeated code between repos 🚩Hard to maintain data integrity between DBs 🚩Requires many HTTP calls to load a page (there's no BFF) 🚩No easy way to search/navigate between repos 🚩Complex cross-service transactions 🚩Doesn't honor Conway's law

Did you ever read „requirements“ written down by business people? It is pretty rare that they are precise enough to be coded down. Hardest part in IT is to understand what business really needs.

In 20 years of engineering I've never said, "thank goodness we hired someone who can reverse a b tree on a whiteboard while strangers watch"

"Существует два типа языков программирования: те, на которые все жалуются, и те, которые никто не использует" — Бьёрн Страуструп

#PhpStorm #Git Tip: View the history for a selection without using the terminal.

1. Make a selection
2. Right-click the selection
3. Click "Git"
4. Click "Show History for Selection"

Oh man, just found that CTRL+M on a Mac (CTRL+SHIFT+M on windows) will jump to the matching brace in #PHPStorm. If you have a massive block with lots of nested conditionals then this is a life saver.

Refactoring is not something distinct from writing code. It's integral to writing code. I do it constantly as I work. By reflex. I see something that can be improved and I improve it. Refactoring is not just something you do when tests fail. Doing it without tests is risky, tho.

Reducing Work in Progress (WIP) is perhaps the most important single thing you can do to improve productivity. An unfixed bug is Work in Progress. You cannot move quickly if you cannot trust the code. Don't log the bug, fix it.

Persistent Terminals.

Loading a project in PHPStorm will also load the terminals you had set up before you exited the last time. I like renaming my terminals to keep my processes separate. That gets saved and reloaded every time too.

Using else often encourages complexer code structure, makes code less readable. In most cases you can refactor it using early returns.

When writing code, it's important to distinguish between INTENT (what is happening) and IMPLEMENTATION (how things work).

“A function should do one thing”

Nah, a function should have one goal. It’s okay for it to do more than a single thing (even without splitting) as long as any codepath taken through it achieves the same goal, and doesn’t do things unrelated to that goal.

1. make it work
2. make it pretty
3. make it fast but don't forget to (only) think about #3 even before you start with #1

Every codebase eventually grows technical debt. Requirements change, things that used to make sense no longer don’t. People who came up with them aren’t around anymore.

When tech people say our world isn’t deeply messed up, I’m confused. It’s the biggest legacy system out there.

As a founder and CTO, I have seen my company grow from when I used to write all the code, to the point I wrote almost none.

When I decided to write and sell my first ebook, The Tech Resume Inside Out, I expected to learn about the writing process. How to create a high-quality publication. How to work with editors. Designing a cover and illustrations for the book. And I have, indeed, learned plenty on these topics.

Try to make your code as readable as possible and less complex. When working with conditions, get rid of invalid cases first, by exiting or throwing exceptions, and do the real logic later. It's called "Early return pattern" as the functions return as soon as possible

You might have the worst codebase in the world.

It was written by people who had no standards or didn’t care about code quality.

It was a late evening.

My colleague has just checked in the code that they’ve been writing all week. We were working on a graphics editor canvas, and they implemented the ability to resize shapes like rectangles and ovals by dragging small handles at their edges.

The code worked.

I'll write a little bit about a topic that is not related to code, seemingly not that important, but it is quite practical in daily programming. How to write git commit message properly?

Feature programming:

1 day: ~1000 lines of code.

Bug fixing:

1 day: ~10 lines of code

Performance fixing:

7 days: 1 command line flag in a config file inside of docker file

A year ago, I started working full-time at Bloomberg. That’s when I imagined writing this post. I imagined myself to be full of ideas that I could spit out on paper when the time comes. Just one month in, I realised it won’t be that easy: I was already forgetting things I learnt. They either became so internalized that my mind tricked me into believing I always knew them, or they slipped my mind.

Only just discovered that in @phpstorm you can save your open tabs as a context (and even link to a task) so you can switch tasks without having to remember all of the files you need to reopen when you return to it!

programming progression

year 0: I know nothing
years 1-2: I know some things
years 3-4: I don't know what I don't know
years 4-4.5: I know everything
years 4.5-10+: I know nothing

I work in IT, which is the reason our house has:

• mechanical locks
• mechanical windows
• routers using OpenWRT
• no smart home crap
• no Alexa/Google Assistant/...
• no internet connected thermostats

Once I was working in the software development company. It was a regular company: nothing really bad, but nothing fancy. It had the same problems as other similar companies:

• Low-quality code
• Unmet deadlines
• Budget overflows

And disappointed clients as a final result.

"Weeks of coding can save you hours of planning." - Unknown

#phpstorm tip: code completion with tab will replace, and enter will add. I’ve always used enter, and then had to delete old leftovers in code.

If you are a new programmer I just want you to know

me and all of my colleagues with years of experience

Google the most basic things daily

Dev pro tip:

• Eat well
• Sleep well
• Take breaks and do non-dev shit

Dev shit tip:

• Pound energy drinks
• Pull all-nighters
• Do nothing but work because EXTREME DEV FTW wait this sucks oh god

“People have an enormous tendency to resist change. They love to say, 'We've always done it this way.' I try to fight that.” - Grace Hopper

2 hours stuck debugging problem last night.

Fixed in 4 seconds this morning.

Managers: want productive devs and fewer bugs? Make sure they have frequent 3-hour blocks with no interruptions. Quiet spaces.

What's an Effective Engineer?

• They are the people who get things done. Effective Engineers produce results.

"First do it, then do it right, then do it better." - Addy Osmani

Friendly reminder: if you allow users to register email addresses on your domain, make sure they can't get:

admin@
administrator@
hostmaster@
postmaster@
webmaster@
(and others from RFC 2142)

otherwise users might be able to get an HTTPS certificate for your domain.

Code reviews are not for your team to be human linters. We have tools like ESLint & prettier to take care of that.

Code review is to catch larger code issues. Not syntax.

Front end software development is:

• real-time (instant load, 60fps)
• distributed, incremental (synchronize remote data as needed)
• asynchronous
• reactive (react to user actions in realtime)

Front end is the hardest kind of dev I do. The folks who do it every day are heroes.

In February, an engineer I’d managed for over a year moved to a new team. In one of our last 1:1s, I mentioned that he’d recently done some good project management. He replied that he’d had an epiphany about self-direction; he’d decided that he needed to own everything about his work, not just his code, to make sure his projects succeeded. I was impressed with him and, instantly, disappointed in myself — I’d long considered ownership the most important thing for young engineers to learn, but I’d somehow left this engineer to discover that for himself.

Being a developer is a long journey. It begins right after you learn to code and start your first job. This journey has different phases. Junior, senior and expert are part of the those phases that a developer may go through. Today I want to talk about another phase. It is a tricky phase which is really hard to spot.

if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking

Your data is immutable? You've adopted ES3074? You've functionally predictive?

Nobody cares.

Does it solve the problem? That's the job

Speed of development always wins. Performance problems will (eventually) get engineered away. This is nearly always how technology changes.

Actual talents involved in programming:

• naming things
• introspective thinking
• explaining things to other people clearly

Софт постоянно усложняется. Стабильность и простота расширения приложения напрямую зависят от качества кода.

К сожалению, почти каждый разработчик, и я в том числе, в своей работе сталкивается с кодом плохого качества.

Several people asked: Q: How do you avoid tech debt at Stack Overflow? A: We don’t. No one can. We constantly allocate time to fixing it.

Tech debt:

1. Realize you have it.
2. Care.
3. Fix it.
4. Enjoy faster development, fewer bugs, and more time doing whatever you love.

Disappointment occurs when expectations don’t match reality. And our expectations for software quality are profoundly unrealistic. Thus, lots of people are continuously disappointed — even enraged — by software bugs. They shouldn’t be.

Programming is a constant struggle between "What is harder: Implementing it myself, or understanding the existing, undocumented solution?"

There is a correlation between startup success and code quality. Unfortunately it's negative.

When reporting a bug to an engineer, never ever ever say “it’s broken”. Instead, say “when I did X, I expected Y, but got Z”. Trust me.

Junior Dev: thinks they know everything

Regular Dev: thinks they know nothing

Senior Dev: hates computers

“We want to limit the length of a review in the product to 140 characters, because we may want to use SMS at some stage. That’s a small change, right?”

Wrong.

to get a project right, you should plan a major code refactor around 3/4 time in the development schedule.

As a programmer it’s your job to avoid writing code as much as possible.

protip: if the language allows it, put a comma at the end of a multi-line data structure. merge/rebase will work correctly more often.

One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper

Pro tip: Unit tests take less time to write than they will save you.

В этой статье я представляю модель разработки, которую использую для всех моих проектов (как рабочих, так и частных) уже в течение года, и которая показала себя с хорошей стороны. Я давно собирался написать о ней, но до сих пор не находил свободного времени. Не буду рассказывать обо всех деталях проекта, коснусь лишь стратегии ветвления и управления релизами.

One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.

Программисту не нужно образование. Только опыт программирования и желание думать головой.

Я надеюсь, что как грамотный разрабочик, вы имеете представление о unit-тестировании и сделаете себе в голове пару мысленных отметок о том, чего надо избегать при написании тестов.