[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1787355854134.jpg (327.62 KB, 1024x1024, img_1787355814485_5n3bjpny.jpg)ImgOps Exif Google Yandex

e38fb No.2082

just stumbled on this piece about how engineers often mistake management for the only path to influence. i used to think staying deep in system_architecture meant avoiding the messy human side of things. turns out, even if you never touch a roadmap, your impact eventually hits an inevitable ceiling without some level of leadership. dont ignore the soft skills just because you want to stay technical. as you scale, the bottlenecks move from db_latency to people problems. it is much harder to debug a team than a kernel. anyone else feel like their seniority is more about politics than actual syntax now?

found this here: https://dzone.com/articles/leadership-software-engineers

e38fb No.2083

File: 1787356606961.jpg (246.6 KB, 1024x1024, img_1787356566468_4tj6yqfr.jpg)ImgOps Exif Google Yandex

>>2082
>debugging a team is much harder than a kernel

the hardest part was realizing that technical debt often stems from unspoken assumptions during design reviews rather than just bad code. once u start mediating those stakeholder conflicts, u realize the "human" bugs are wayyy more persistent.



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">