usually write stuff down that i keep repeating in discussions

- eg management advice: https://klinger.io/posts/managing-people-%F0%9F%A4%AF

- eg my angel-investment decision making process: https://klinger.io/posts/how-i-make-investment-decisions

- eg simple productivity-hack: https://klinger.io/posts/q-codes

Comments URL: https://news.ycombinator.com/item?id=32729263

Points: 39

# Comments: 29

It's literally changing the map of the world, shifting the access (and use) of resources and the livelihood of people worldwide.

Not that i think it's a good thing that this needs to exist but mitigation and adaption to this change will be a huge industry.

Comments URL: https://news.ycombinator.com/item?id=23548197

Points: 19

# Comments: 13

Have a person that has call with the new intern every day for the first 1-2 weeks.

Blocked to be 30mins, meant to be 15mins.

It allows to "bring stupid questions / blockers" to the next day's meeting. It create bonding and team culture understanding.

Here a few learnings:

1. the community already exists, you just create a communication platform for it

2. make it clear what the community is about [positioning/marketing]

3. make sure the communication/content is interesting [quality]

4. make sure there is enough engagement [perceived critical mass] (encourage people to post, post yourself a lot, fake accounts if needed, only create subforums once the main ones are noisy)

5. have a rhythm - some communities need daily good posts, some live of the weekly newsletter

AngelList has the largest amount of remote jobs right now out there

(Disclaimer: work at AngelList)

What's important is that you have rigorous testing around your API.

APIs are essentially external contracts people build against. You don't want to break this contract.

make sure it

- never changes unless you know about it

- updates the documentation whenever it changes

Comments URL: https://news.ycombinator.com/item?id=19799703

Points: 3

# Comments: 1

you can use stars OR labels - no point using both

you have extra inboxes for each kind on the side

you read in your inbox you act (potentially reply, potentially mark with star/label, always archive)

if it's a todo you dont get to now you put it in the todo label if you replied and want to make sure you dont lose track -> awaiting reply if you handed it off to someone and want to keep track -> delegated if it's about some future meeting (or flight, hotel, etc) -> purple star (forgot what i called it)

you always archive this way your main inbox is empty and you know what you looked at by adding (or removing) label they end up (or get out) in the little boxes

at some point you might go through your todos - handle them remove the star/label

at some other point you might browse through the awaiting replies and realise they are done or no longer needed -> remove label

(and so on)

works really well for me

hth

main reason i never switched (even with all compromises) is that i didn't want to be forced to switch back if i pick the unlucky one (eg google inbox)

or mark as "delegated" if someone else of my team is handling it and i might want to keep track

i updated the comment to explain this (hopefully) better

Two assumptions: You plan to work on this longer-term (not a 1month project stint) and there are things worth improving (eg barely used legacy app might not be worth your time)

#1 Get the team on board

if there are multiple people you need their buy-in and support for whatever approaches you want to do

#2 Plan for "health by a thousand small improvements"

it will be an iterative approach and you will refactor as you go.

#3 Don't assume different = bad

people might have done differently, consider using their approaches. you might do it differently. but it's better if you keep a consistency within the codebase. in codebase management consistency trumps cleverness

#4 Create space

Consider introducing a fix-it friday where everyone can work on little improvements

#5 Create non-blame culture

Stuff will break if people risk improving things. Avoid blame shifted to them. If bug trackers ping individual people consider pinging the whole team instead

#6 Consider automation

introduce linters, autoformating, codemods, danger.js, code complexity analysis, etc

#7 Introduce tests

This one is the most annoying. But worth doing: whenever you improve a feature a bit try adding a test - often in legacy apps there are no good tests. A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do this try it. I always found the iterative approach more realistic as you can also do feature work while refactoring.

When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the "unit" contains critical or complex logic). Your goal is to know "that you broke something" - you get by if you don't always know "what you broke"

#8 Acknowledge tech debt

not everything needs refactoring. If it's not critical and nobody needs to touch it consider acknowledging it as tech debt. Add larger notes above the problematic areas and explain why you aren't refactoring it, explain things worth knowing to understand the code better, etc. Whenever you leave comments remember that comments should explain "why" not "what" the code does.

hope that helps! good luck.

actually it's famous for the second one

thanks for posting the article on HN - i am a daily (more or less) lurker and a huge fan :)

let me know if any parts in the article aren't clear or major points are missing - happy to extend or answer here