Hacker Newsnew | past | comments | ask | show | jobs | submit | more catwind7's commentslogin

I can relate to a lot of this. One thing I learned about myself recently is that I tend to default to programming because it practically guarantees that I'll feel good (dopamine from making things work, fixing bugs). Since I don't have many other hobbies that guarantee similar reward, there's not much of an incentive for me to do anything different whenever I'm feeling antsy about sitting around and not feeling productive.

one thing I've been doing with the help of some therapy recently that's somewhat helping is scheduling time (1 hour) to NOT program. No expectation of actually doing anything and accepting any uneasy feelings that arise. Just making sure that I make the time to tune in to feelings / thoughts without the option of picking up my computer as a sort of pacifier.

first time I did this, I just sat nervously for 30 minutes until I got bored and then looked for problems around my house to fix (which took 2 hours and was pretty satisfying). After a few rounds of this I noticed myself acting on small, non-programming interests outside my scheduled times.

just figured I shared in case others are feeling same and want something to try :)


mixed feelings about this not being the top comment


fantastic :)


agree with this ^. Pretty sure the book was written with STEM (but really, comp sci) new grads in mind


agree with the adaptability of change requests from clients, but i would say only insofar as the design issues you're mentioning are actually addressed as quickly as they are surfaced. Otherwise this type of building eventually grinds to a halt.

another commenter sort of hinted at this, but this type of process has a downside of prioritizing short term design decisions that lead to working code. It takes time and sometimes a lot of thought to think about the system and the problems deeply and ask yourself if you've created the right primitives.


this made me chuckle


> When tech debt sand gets in the software delivery gears, the allure of vendors increases

Well put. Could not have said this better myself. I've experienced situations where the tech debt sand is a consequence of fairly unique business and internal system constraints. The allure of vendors did increase and the company did eventually research vendors, but nothing addressed our snowflake use cases perfectly.

I don't think that's necessarily a positive reflection on our product though. If anything, the lesson I take from that is to build your business processes and teams to reduce as much accidental complexity as possible.


Looks great! :thumbsup:


different companies need different skills and it changes even as a company grows. Part of the frustration about this entire process is that it feels very cookie cutter and sort of like a lowest-common-denominator type effort on behalf of companies.

Huge companies like google are for the most part hiring people they can slot into almost any team in the org so it makes sense for them to place less emphasis on tooling expertise. They have plenty of time and money to upskill employees.

The same can't be said for the vast majority of consumer start ups that really just need people who can rapidly prototype.

Of course those groups are not mutually exclusive, I just think it's sad that everyone has adopted the approach that works for a select few companies


Most places will also probably have you spending a good chunk of time maintaining legacy code rather than inventing entirely new business units / products / platforms. I can't imagine what the maintenance burden is like at huge companies for existing / mature products. Anyone care to shed some light?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: