Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code the shortest path first

evanlh.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Code the shortest path first

#101

Post by imtringued »

maverwa wrote: post #74
hkon wrote: post #67

For sideprojects, definitely, there is simply not enough time otherwise.

For me, its not just time, but also motivation. I cannot count how many site projects died in the early days, just because I came up with this impossible perfect thing it should be, having all the things. Then implementing it becoumes a chore. The amount of code/time I'd have to invest to make this imagination a reality becomes a mountain I cannot climb. Either because a lack of skill/knowledge, time, motivation, ded…

Well kept secret: If you want to get things done, keep the scope within something you can actually do.

If you are unhappy with the fact that you planned to do more, then congratulations, you can just get things done again!

Re: Code the shortest path first

#102

Post by OkayPhysicist »

ZaoLahma wrote: post #64
Etheryte wrote: post #22

Earlier quoted context omitted.

There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.

Does not work and makes life worse. I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company. So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API…

How inflexible do you have to be that nobody on a team bothered to pick up C#? Java and C# are probably the two most similar languages that are still considered distinct.

Re: Code the shortest path first

#103

Post by imtringued »

xyzzy123 wrote: post #40
friendzis wrote: post #20

Earlier quoted context omitted.

> For the vast majority of any task that requires writing code, performance is the least of your concerns; I always have conflicting thoughts when faced with such statements. On one hand, you are right - in many cases any single code unit you write is not going to be the performance bottleneck anyway, and if it is you can optimize it later. On the other hand, there are scaling characteristics, both algorithmic and ar…

Also conflicted, but I find myself happier working with "the dumbest thing that barely works" for a first release of something. To me, this is "optimal engineering under uncertainty". Obviously, there are limits. And maybe a difference in perspective here reflects our respective typical uncertainty. I'd rather optimise based on user feedback and with production traces than "in a vacuum". Very often I don't even know…

>To me, this is "optimal engineering under uncertainty".

Information acquisition costs are the worst, aren't they? They are everywhere and they don't appear neatly on your bill.

Re: Code the shortest path first

#104

Post by OkayPhysicist »

t43562 wrote: post #11

Usually one understands a project poorly at the start and much better at the end. So to agree with the article I think it's unwise to make all your decisions at the point where you know the least. By getting something working you improve your understanding and then you can choose optimisations and abstractions in a judicious manner - no point in optimising things that end up having no impact and no point in introduci…

> There are those who imagine that you can completely plan work before lifting a finger

My response to these types is always to point out that we already have tools that translate a complete plan of a project into software: They're called compilers, and that plan is source code.

Re: Code the shortest path first

#105

Post by irq-1 »

i-use-nixos-btw wrote: post #9

An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes. Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at fir…

“Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.”

- Fred Brooks

Re: Code the shortest path first

#106

Post by ZaoLahma »

OkayPhysicist wrote: post #102
ZaoLahma wrote: post #64

Earlier quoted context omitted.

Does not work and makes life worse. I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company. So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API…

How inflexible do you have to be that nobody on a team bothered to pick up C#? Java and C# are probably the two most similar languages that are still considered distinct.

It was never about competence. Most of us were of different backgrounds.

It was about the need to track down, secure licenses for and install the dev environment that you'd use for those 4-8 hours per year that it took to add support for the new API.

The entire company lived in the JVM otherwise.

Re: Code the shortest path first

#107

Post by evandale »

Pannoniae wrote: post #33
Shaanie wrote: post #29

Earlier quoted context omitted.

Another way to think about it is that software that focus on performance loses market share to software that focuses on other things.

And that's a perverse incentive, and we must evaluate why that is the case. It doesn't have to be that way.

It probably has to do with the fact that a lot of people are patient enough to wait 10 seconds for something to finish if a) they understand it and b) it does the job.

The average person will put up with a lot of friction to use something they're familiar with and needs a lot of incentive to change. If your thumbnails fail to load every 10000 times or every 100000th profile picture upload fails most people will just retry and hope it works the second time, not find a different service or app to use.

Re: Code the shortest path first

#108

Post by gcanyon »

I fell deep into this trap just yesterday, solving a Project Euler problem in Python. It involved a 2-million+ digit number. I'm just starting with Python, and while I know it transparently handles large integers, out of an abundance of caution I spent an hour optimizing to avoid dealing with greater-than-64-bit values, since the result needed is modulo a My code ran in about 4 seconds.

Then I thought I'd try a slightly larger optimization that involved ~128 bit values. That ran in a second, so obviously the switch to large integers either doesn't happen at 64 bits, or Python just handles it really well.

Then I thought to just do the math and let Python sort the results. One line of Python. Took ~20 seconds to write. Calculated the 2-million digit number and then did the modulo. Ran in a small fraction of a second.

Re: Code the shortest path first

#109

Post by pyrale »

mejutoco wrote: post #77
pyrale wrote: post #60

Earlier quoted context omitted.

> Those are political problems, not technical ones. [...] TLDR. A PoC is a PoC, not a full product. Politics eat technnological semantics for breakfast though. It's up to you to decide whether this is a hill you want to die on. > They can be solved by aligning incentives. Often enough, that means shipping the poc.

> Instead, when a PoC is done everybody involved needs to understand the implications. > Politics eat technnological semantics for breakfast though. I see where you are coming from, but I have to disagree. I am not debating semantics, but reality. A prototype will always have limitations. That is the definition of a prototype. I understand in reality sometimes it is worth to push through (startup), and sometime it is…

> If you want, Nature/laws of physics eats politics for breakfast :)

It would be that politics eats tech, but culture eats politics.

And strengthening your PoCs is a predictable cultural consequence of any organisation where leadership forces PoCs in production.

For leadership to align incentives is to prevent engineers from suffering the consequences of PoCs pushed to production. What you described may work in some situations.

> A certain amount of back and forth is healthy and can produce much better outcomes for the company.

The reaction I described is a kind of back and forth, if a bit conflictual. However, it's leadership's responsibility to ensure that communication happens in a non-conflictual way.

Re: Code the shortest path first

#110

Post by jstimpfle »

herval11 wrote: post #96

Once you become super senior you actually realize what the author said here is not completely correct. This guy has experience, but he hasn't reached nirvana. There is a singular high level design pattern/abstraction that you can use in actuality to start off your projects. There is no name for this pattern but it is essentially this: Segregate io and mutations away from pure functions. Write your code in modular com…

IME, separating I/O in the code works because it literally is separate -- it usually happens at the boundaries of the application. It rarely makes any sense to connect two code components (running in the same process) with a disk-backed information path. And where it does make sense -- well, your I/O code moves deeper inside the application.

The "boundary" argument works even better where it's about network I/O or video output, because applications are even less likely to connect code modules using such types of data.

Other than that I don't buy much into that I/O vs "pure" at all, it's pretty much an arbitrary categorization since there really isn't much of a difference between writing to disk or memory. I think the idea that writing to memory is somehow purer comes mostly from Haskell and similar languages that somewhat enforce immutability at the language level. Given that it is still an artificial categorization I don't take this too seriously. The one benefit I see is that it often does improve clarity of architecture to have mostly construct-consume-discard data access patterns without any mutability after construction. Oh, and potentially you can handle errors from disk I/O, while you cannot really handle errors from memory I/O.

Post reply on HN