Learn to Look Around Corners | Hacker News Reader

Learn to Look Around Corners

letterstoanewdeveloper.com

64 pointsmooreds27 comments

It takes experience to understand these corners. This is where senior leads and archs should be providing insight and guidance to a team.

Relational v Document DB. Python v Java. Message bus v RPC. Where on the mono/micro axis to land.

I don't know how to transfer that knowledge to a new dev other than experience and mentorship. As it takes a lot of business domain knowledge and soft skills to anticipate the type of ripples any decision will make. Even the ripples that you intentionally make like, let's crank out this MVP in Rails/Django with the knowledge that we will be rewriting this entire thing three years later so we can get this to market now.

Ah, so development in the long-term is like chess. I need to think at least 5 moves ahead, ideally.

Got it.

I wonder when I'll be done with my initial analysis, so I can finally start building, but I suspect it'll be 3 months from now as I need to evaluate a lot.

But after that, I can strap on my rocket ship and go to the moon with my product.

Oh, nobody wants my product. I guess I should've created a crappy prototype first.

Ah, I see that people want my product with my crappy prototype. Wait, what? We're 1 year down the line still working with our crappy prototype code as a base and now our competitors are building much much faster than us? (You should've gone with Lisp and not C, buddy)

How on earth am I supposed to do this right?!

Oh, there's talk about this team that didn't build anything but just did market research and then started building it [1]. That might be a way to go, but how do you know when you simply talk to people they'll be correct in what they say about their own future behavior? Where they just lucky. I suppose it worked for that company.

Oh wow, Nomad List just started out as a Google Spreadsheet? [2] I guess that's one way to go! If that's applicable to your particular app.

Oh, and this particular game developer does actually show a history of having prototype code and then just updating his development stack and workflow practices, so I guess in some cases it can be done [3].

I guess, I'll just write up a guide of potential actions one could do and see which is applicable to which situation. I'll also talk to some senior devs and ask how they do it.

Man, the real world is complex!

[1] From the book Traction.

[2] Pieter Levels his story: https://levels.io/product-hunt-hacker-news-number-one/

[3]

See the game: https://www.youtube.com/watch?v=HIsCYHpCfVc

Read about his development style: https://www.reddit.com/r/asciicker/comments/d3ca43/whats_goi...

Brilliant! Thank you.

Doors and corners, kid. That's where they get you.

You run into a room too fast and the room eats you.

Sasa ke beltalowda!

Unfortunately, developers rarely learn to look around corners until they have been burned a few times by not doing so (and often burned everything around them in the process).

The looking round corners starts with things like not using email addresses as primary keys. I mean the developer before this one in the article built a wooden hut and splashed petrol all over the walls. Blaming someone else for lighting a match is kinda missing the point.

Yes consider the knockon effects, but be sensible and build firebreaks

I don't necessarily agree here. An email address is itself a globally addressable primary key. In a lot of real world systems, the benefits of abstracting that are lower than the costs.

But it isn't immutable in the long run. That is, the same entity may have more than one email address over time.

You are not looking around the corner.

I always say that people pay more for senior developers because they've made mistakes on previous employer's dimes.

I have seen this first hand. It is also very common to have an “original sin” in the form of a schema design. In the short term maybe it’s easier to just have a single table for “events” and add new fields to that to decorate specific event types... until you have thousands of event types, extremely sparse records, name collision, columns named the same things but with different casing or underscores, and realize you need to split it out

For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture. How to design the software so that these kinds of changes can be made late and they are not a major work is also a skill to be learned.

the example given is not wise to attempt to fully isolate in your architecture and design. A NoSQL database brings with it an entirely different approach to your data, and as has been pointed out many times, the core of every software system is its data. If you are choosing a NoSQL database, you should be confident you know why you are doing so, but you should not imagine (or attempt to pretend) that you will be able to isolate your code from that choice.

> A NoSQL database brings with it an entirely different approach to your data

NoSQL has no specific definition, so no it doesn't necessarily bring anything different.

> the core of every software system is its data.

That doesn't really mean anything. One could also say that the core of every software system is its use cases.

> isolate your code from that choice.

It is very important to isolate code (e.g. business logic) from the specific details of how you persist your data.

> How to design the software so that these kinds of changes can be made late and they are not a major work is also a skill to be learned.

And when it is worth the effort.

To be fair to the nosql example in the post, the company in question was an early stage startup. And in those situations available skillset and time to market can and often does outweigh long term flexibility.

> For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture.

Choosing what kind of database to use isn’t really an “implementation detail” as much as it is a “major, foundational architecture decision”. Taking tabular, relational data and putting it in a document DB (which I’d be willing to bet is the most common NoSQL use case) makes about as much sense as taking the same data and putting it into a graph DB. You can make it work, but everybody who does this runs into exactly the same problems over and over again. Perhaps this is a sign of how dysfunctional some technology trends are, but I can’t see it as an indictment of software architecture in general.

I'm 50% disappointed that this wasn't about actually learning to see around physical corners, and 50% embarrassed that for a fraction of a second I thought this was going to be about learning to see around physical corners...

I recommend a mirror on a stick.

http://news.mit.edu/2017/artificial-intelligence-for-your-bl...

Kate also has some videos with the technical details.

An object around the corner will have a minute but detectable effect on the light adjacent the corner.

Yes, this is the same Kate Boumann of black-hole-imaging fame.

Oh, wow! I had seen this video back then, but had no idea it was from the same person! Thanks for pointing it out :)

https://www.media.mit.edu/projects/looking-around-corners/ov...

Ok then here, buddy!

https://www.technologyreview.com/s/603314/new-camera-can-see...

It's actually possible, here's the first time I ran into this: (from 2012)

https://newatlas.com/camera-sees-around-corners/21892/

I'm a fan of this method: Dual Photography from 2005

https://youtu.be/p5_tpq5ejFQ

Thanks for saving me a click.

Reply on news.ycombinator.com