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

From where you're coming from, I think, your next steps would be thinking "who should work on this" vs. "I'll pick this up because I can do it quickly."

If you're not enabling your team to take over your job, you're doing it wrong. And by a comment I saw elsewhere, the tendency to control things is natural, but you should resist that - it's the only way you can scale.

If your organization doesn't have that kind of individual contributor leveling, that would be a good conversation to have. Or if your team isn't big enough, maybe its time to look for a new challenge.

There will be a learning curve and a mindset shift, but it's really the only way that you truly become a force multiplier.

Soon, your commits will go down, but your reviews will go up.

Later, your reviews will go down, but your strategy/design/planning docs/conversations will go up. Your job is designing for the 1-3yr future (or more but rare) and across the organization.


This is a great way to lose your best people. Or it's pure /s


Not if handled right. Remember those unimportant projects are often self-assigned as try the latest thing to see if it is useful to us, and they often get high visibility to management as cool things we want to do next.

Of course if this is only treated as unimportant projects they will leave.


Maybe a better term would be "critical projects" instead of "important projects" in that case?


Curious - how do you end up handling transactions that span services?

I'm getting into go, but there doesn't seem to be a great pattern for this. Used to @Transactional on the service, so feels annoying in having to build that.


I think the answers requires more context, but for example one well known pattern is called “sagas” for implementing long lived distributed transactions.

The gist is you timeout but provide a way for transactions to resume.

Also obviously there’s 2PC but again it depends on what unite trying to solve.


How does @Transactional span services? With a JtaTransaction manager?

If you are saying about micro services here which talk grpc/http then @Transactional does not help.

If you are talking about inside one service then you have write all that boilerplates, and it will not look as simple as Java


Those salaries exist around the minneapolis/st. paul area at a few of the larger corps nearby.


Can confirm and the upside is that cost of living is still manageable.


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

Search: