3,127 karma · joined June 29, 2010
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
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.
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
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
it switches from "1 minute: buy pancakes in store" to "50 weeks: Let your seawater sit in the sun"
- Easily the best sci-fi show in 10 years(1)
- Latest season has a 100% score on rotten-tomatos
- The visual effects are absolute top of the art (2)
- The fanbase is franticly close to the show (look at twitter how much they interact w/ the cast etc)
- Season 3 and we are about to start the big turn of the story arch
BUT… Canceled by Syfy because not enough people catch it at the time they happen to transmit it into the air.
If this show would be on Netflix it could become on of the defining sci-fi shows of our generation. Now we have to hope Netflix or Amazon happen to pick it up before the team disperses. (3)
(1) seriously watch it… the first few episodes are a bit slowish worldbuilding but it gets really good
(2) https://www.youtube.com/watch?v=6yKn_EqA0ik (shitty rip unfortunately)
(3) Please sign: https://www.change.org/p/netflix-or-amazon-please-buy-the-ri...
imo you address two things here very well
- who pays for infrastructure
- how do you do governance
imo the second one could be solved if you decided how you want to do the first one.
the technical details (eg performance) is almost it's own discussion imo - there are people who are better experienced/educated to answer it fully qualified.
But very often they can't do the optimal prices or all the inventory - eg stock not listed on nasdaq - so it comes down to "are you able to move quickly/cheaply" (and/or is the inventory able to move quickly/cheaply)
A (naive [in details] weak) example i regularly use is electricity:
Imagine you own solar roof panels and produce more electricity than you need. You want to sell it back. But you want to sell it at the highest possible price to the best payer.
The centralized concept is that you sell it to your main provider and hope they pay the best price (or that your are able to move cheaply/quickly enough). Or that you sell it to a intermediary (or price-comparison service) that hopefully has the lowest rate (or that your are able to move cheaply/quickly enough).
The decentralized approach to this is to announce the sale on the network/market and pick the best offer.
but… this will be the primary usecase of blockchain projects.
Players on markets agreeing to use one common protocol and compete for prices in real time.
It won't be the incumbent who wants to do this or change. (it never is) It will be the powerlaw distributed Number 3 to 99 who together are alone barely competitive but together as interesting as the main incumbent.
i always assumed it to be named as a nod to zuse the famous german computer pioneer.
but you might be right - might just be coincidence
Related to this: In the 80/90s i saw a German BASIC variant floating around. Unfortunately i couldnt find it online
But… if you are into alternative-language programming languages i highly recommend you reading up on Plankalkül[1] - written by Zuse (after whom SuseLinux is named) which inspired ALGOL
Also worth knowing about is obviously GERMAN[2] a programming language much like brainfuck that is redused to only the most important German words.
Example code
SCHNITZEL BEER BEER BEER BEER BEER BEER BEER
SCHNITZEL BEER SCHNITZEL SCHNITZEL SCHNITZEL BEER SCHNITZEL BEER
SCHNITZEL BEER SCHNITZEL SCHNITZEL BEER BEER SCHNITZEL SCHNITZEL
SCHNITZEL BEER SCHNITZEL SCHNITZEL SCHNITZEL BEER BEER SCHNITZEL
> The core problem with the NYC subway system is a management culture that does not value long term problem solving, instead preferring quick fixes and short term band aids
Do they have the time and budget horizon to do long-term planning ?
To me it seems like SF and NY subways are underfunded
Most people tend to overestimate the quality of the majority of meat consumed - it's not filet steak
It's ground beef, sausages, pressed shredded chicken, thin strips, etc, etc