Evgeny Tronchuk

Blog Insights
Follow me on Twitter (X) Follow me on Telegram Follow me on Instagram Go to my GitHub repo
Все ★ Найкраще #Learn to live126 #Productivity118 #Learn to work82 #Dev76 #Entrepreneurship63 #Leadership54 #Indie Hacking53 #Product26 #Remote24 #Design23 #Health21 #Money20 #Marketing19 #Blogging15 #Goals12 #AI11 #Communication11 #Technology10 #Knowledge9 #Making9 #Digital7 #Education6 #Kids6 #Networking5 #News3 #Sales3 #Stuff2 #Travel1
  • In defense of simple architectures

    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.

    Читати далі ›
    #Dev
  • flavio
    @flaviocopes

    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

    #Dev
  • Cory House
    @housecor

    📢: 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.

    #Dev
  • The radiating programmer

    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.

    Читати далі ›
    #Dev #Leadership
  • Jacob Tobiasz
    @jakub_tobiasz

    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.

    #Dev
  • Marc Lou
    @marc_louvion

    Stripe subscriptions could be a real headache...

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

    #Dev
  • Kernighan and Pike were right: Do one thing, and do it well

    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.

    Читати далі ›
    #Dev
  • Smart Guy Productivity Pitfalls

    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.

    Читати далі ›
    #Productivity #Dev
  • Max
    @maxua

    Щоб не "застрягнути" на $5,500* назавжди робіть свій стартап або йдіть працювати в існуючий що злітає.

    (*) мова про Україну, цифри від Djinni https://t.me/djinni_official/1022

    #Dev #Entrepreneurship
  • Austen
    @Austen

    "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

    #Dev
  • boris tane
    @boristane

    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

    #Dev
  • Wilson Wilson
    @euboid

    GPT-4 just localized my entire app

    #Dev #AI
  • Benjamin Crozat
    @benjamincrozat

    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! 😮‍💨

    #Dev #AI
  • Cory House
    @housecor

    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

    #Dev
  • Christian Hufgard
    @musikpirat

    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.

    #Dev #AI
  • 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"

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

    #Dev
  • Matthew Setter
    @settermjd

    #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"
    #Dev
  • Christian. not Chris.
    @NoNotChris

    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.

    #Dev
  • Allen Holub allenholub.(mstdn.social,bsky.social)
    @allenholub

    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.

    #Dev
  • Allen Holub allenholub.(mstdn.social,bsky.social)
    @allenholub

    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.

    #Dev
  • Richard H. |
    @DevByRich

    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.

    #Dev
  • Avoid using else

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

    Читати далі ›
    #Dev
  • Reveal intent, hide implementation

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

    Читати далі ›
    #Dev
  • “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.

    #Dev
  • Oliver Kriška
    @quatermain32
    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
    #Product #Dev
  • 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.

    #Dev
  • Staying Technical as an Engineering Leader

    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.

    Читати далі ›
    #Dev #Leadership
  • Want to Learn about Entrepreneurship, as a Software Engineer? Sell Something Online.

    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.

    Читати далі ›
    #Dev #Entrepreneurship
  • James Ivings
    @JamesIvings

    Newsletter tip - you can show your brand logo in Gmail easily by adding a BIMI record to your DNS.

    https://mxtoolbox.com/dmarc/bimi/how-to-create-bimi-record

    #Dev
  • Abdessalam
    @itsabdessalam

    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

    #Dev
  • How I think about Code Management

    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.

    Читати далі ›
    #Dev
  • Goodbye, Clean Code

    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.

    Читати далі ›
    #Dev
  • How are you writing a commit message?

    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?

    Читати далі ›
    #Dev
  • 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

    #Dev
  • Things I Learnt from a Senior Software Engineer

    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.

    Читати далі ›
    #Dev
  • Antony D'Andrea
    @antonydandrea1

    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!

    #Dev
  • I Am Devloper
    @iamdevloper

    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

    #Dev
  • Jochen Mader
    @codepitbull

    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
    #Dev
  • Building blameless working environment

    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.

    Читати далі ›
    #Dev
  • Programming Wisdom
    @CodeWisdom

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

    #Dev #Entrepreneurship
  • Morten Bergset
    @mortenbergset

    #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.

    #Dev
  • One Devloper Army
    @OneDevloperArmy

    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
  • aj
    @ajlkn

    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
    #Dev
  • Programming Wisdom
    @CodeWisdom

    “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

    #Dev
  • Mike Coutermarsh
    @mscccc

    2 hours stuck debugging problem last night.

    Fixed in 4 seconds this morning.

    #Dev
  • Eric Elliott
    @_ericelliott

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

    #Dev #Leadership
  • ★ Effective Engineer

    What's an Effective Engineer?

    • They are the people who get things done. Effective Engineers produce results.
    Читати далі ›
    #Dev
  • Programming Wisdom
    @CodeWisdom

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

    #Dev
  • Michal Špaček
    @spazef0rze

    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.

    #Dev
  • Robert
    @robdel12

    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.

    #Dev
  • Yehuda Katz
    @wycats

    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.

    #Dev
  • Ten Principles for Growth as an Engineer

    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.

    Читати далі ›
    #Dev
  • Active Learner — How developers keep learning

    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.

    Читати далі ›
    #Dev
  • ben
    @daisyowl

    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

    #Dev
  • Alex Russell
    @slightlylate

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

    Nobody cares.

    Does it solve the problem? That's the job

    #Dev
  • Laurie Voss
    @seldo

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

    #Dev
  • Jiaaro
    @jiaaro

    Actual talents involved in programming:

    • naming things
    • introspective thinking
    • explaining things to other people clearly
    #Dev
  • Искусство написания простых и коротких функций

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

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

    Читати далі ›
    #Dev
  • @[email protected]
    @Nick_Craver

    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.

    #Dev
  • @[email protected]
    @Nick_Craver

    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.
    #Dev
  • Software has bugs. This is normal.

    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.

    Читати далі ›
    #Product #Dev
  • Programming is a constant struggle between "What is harder: Implementing it myself, or understanding the existing, undocumented solution?"

    #Dev
  • Alex MacCaw
    @maccaw

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

    #Dev
  • Jake A. Smith
    @jakeasmith

    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.

    #Dev
  • About Programming
    @abt_programming

    Junior Dev: thinks they know everything

    Regular Dev: thinks they know nothing

    Senior Dev: hates computers

    #Dev
  • There are no small changes

    “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.

    Читати далі ›
    #Product #Dev #Leadership
  • Bartek
    @bartekd

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

    #Dev
  •  Thomas  Fuchs 
    @thomasfuchs

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

    #Dev
  • Bob Ippolito
    @etrepum

    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.

    #Dev
  • ★ Frequency Reduces Difficulty

    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

    Читати далі ›
    #Learn to work #Dev
  • Luke Smith
    @ls_n

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

    #Dev
  • Удачная модель ветвления для Git

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

    Читати далі ›
    #Dev
  • Maker's Schedule, Manager's Schedule

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

    Читати далі ›
    #Productivity #Dev #Making
  • @[email protected]
    @bobuk

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

    #Dev #Education
  • Анти-паттерны Test Driven Development

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

    Читати далі ›
    #Dev
Follow me on Twitter (X) Follow me on Telegram Follow me on Instagram Go to my GitHub repo
© 2025 Evgeny Tronchuk