andreasklinger

https://klinger.io/

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

I think people here underestimate how much money will be made in climate tech in the next decades.

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.

Quick tip:

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.

She was an amazing and inspiring person.

I helped building producthunt.com and overclockers.at (and other less successful ones)

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

FYI: I would also add angel.co/jobs

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

(Disclaimer: work at AngelList)

Imho it matters less.

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

blog author

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

there were a lot of different tools when i wrote this post several other inbetween

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)

i approach it the same way

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

:)

disagree here but in favor of simplicity of the main message removed it.

Yes - basically saying: just because previous workers did things differently than you would doesn't mean it's wrong

i updated the comment to explain this (hopefully) better

This is super specific to each project but here things that worked for me in previous projects.

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.

citymapper has scooters/bikes and multi-mode

actually it's famous for the second one

I have not read it but it's by Jason Friend and DHH: https://www.amazon.com/dp/B00C0ALZ0W/ref=dp-kindle-redirect?...

author here

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

move the "available time" slider

it switches from "1 minute: buy pancakes in store" to "50 weeks: Let your seawater sit in the sun"

I think the perfect example is "The Expanse"

- 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...

this might be a too complex topic to discuss properly here

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.

for anything that aims to be the definitive market for an asset it would try to make it (as) public (as possible/useful).

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.

Centralized marketplaces / price comparison services / middle men etc exist and do a good job

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)

Decentralized systems allow you to formalize market dynamics. Eg how selling/providing works. Through this you can create marketplaces to which everyone can connect to but nobody can leverage their own position to change the rules.

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.

Not to be a cliche of a tech community comment…

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.

It's a considerate effort to make the language more readable to foreigners

interesting - tried to look up if i am correct - couldnt find any result

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

Awesome stuff - i think this kind of languages are more important than most people (esp with strong english school background assume). I could see this as educational language for kids.

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

[1] https://en.wikipedia.org/wiki/Plankalk%C3%BCl

[2] https://esolangs.org/wiki/German

In a world where there is a coin (literally) named shitcoin[1] how can be dogecoin considered a parody? At least they used it for fundraisers?

[1] https://www.coinexchange.io/market/SHIT/BTC

Non-NYC-er here:

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

Agree

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