It reminds me of Go (not the language). Beginners play straight lines, then one learns fancy moves and complicates everything while high ranked players patterns again exhibit straighter simpler forms.
Code the shortest path first
41–50 of 115 posts
Re: Code the shortest path first
#42Maybe I'm not senior enough, but I think this misses the point. If I'm not prototyping, I don't try to "code the shortest path first", I try to code using the most popular libraries, and the most concrete, broad-strokes, fundamental abstractions, towards a goal of improving understandability. At the end of the day, most code is deleted anyway. But even then people still need to understand it. I am attempting to write…
It's contextual, and the author is presenting it as universal. If you don't know how to build the thing, the author's advice is on the right track. If you're unfamiliar with the problem space, just bang away at it. Write that god object, that 500 line function, hardcode all the things. You wouldn't be able to come up with useful abstractions so don't bother trying. Get your stupid terrible code to work, the tiny demo…
> If you're unfamiliar with the problem space, just bang away at it.
> Write that god object, that 500 line function, hardcode all the things.
> You wouldn't be able to come up with useful abstractions so don't
> bother trying.
In this case, it's not about applying "object-oriented design & algorithms & design patterns & frameworks & abstractions & higher-order functions & monoids & whatever else you found on Hacker News". It could be writing a god object or 500 line function, but only if these are easy to understand.
Basically, I think we should write programs as communication to ourselves and others and as a form of "theory-building". I think our artifacts should fit into this objective and communicate understanding. (I am heavily Naur-pilled, e.g. https://pages.cs.wisc.edu/~remzi/Naur.pdf)
Re: Code the shortest path first
#43I get what he’s saying, but definitely several gotchas. The main project I work on these days has code that definitely isn’t the shortest path already checked in to main and running in prod. I’m that guy- set up ci/cd, apm, upgraded frameworks, and am working on major refactor. I tell management we can move faster on features and bugfixes if we can reduce the complexity of existing code.
But I do struggle with how far to take that. I worry I’m getting too deep and need to focus on features.
Re: Code the shortest path first
#44I agree with the sentiment but not the examples: > spend days setting up a CI/CD pipeline This should/does take minutes. It's like 15 lines of YAML for most CI providers. Ideally it's a part of the template you use for new code. > use a cool new library they just found Integrating a useful lib that makes the code simpler should be done from day 1. Don't code your own platform lib and switch to SDL halfway through dev…
>> spend days setting up a CI/CD pipeline
> This should/does take minutes
Should if you discount tool selection, learning tools, managing access control, deal with technical and organization imposed constraints, documentation and alignment across the team.
Re: Code the shortest path first
#45I think this advice is a little vague and therefore easy to get wrong.
My approach converged to something that can be understood as a form of progressive enhancement, so basically providing the simplest usable version of a given feature, bearing in mind that eventually you'll have to expand it to what was originally requested - but that's all in separate tickets.
Some examples:
Six different payment processors? Start with one or two.
SPA frontend? Start with server-rendered. The tech is there to smoothly transition from one to the other, but it's possible that this will never be required.
That colour picker shaped like a peacock, following the mouse with its gaze? Just use a regular colour picker, but make it easily swappable. Where's that in the requirements anyway?
What's interesting is that more often than not enhancements lose priority in favour of new features.
Meanwhile some universal techniques like preferring pure functions where reasonable, using immutable data structures and actually having an architecture take as much time as doing sloppy work and go a long way into ensuring maintainability.
Re: Code the shortest path first
#46Maybe I'm not senior enough, but I think this misses the point. If I'm not prototyping, I don't try to "code the shortest path first", I try to code using the most popular libraries, and the most concrete, broad-strokes, fundamental abstractions, towards a goal of improving understandability. At the end of the day, most code is deleted anyway. But even then people still need to understand it. I am attempting to write…
> At the end of the day, most code is deleted anyway.
The timescale for that really depend on the project. I'm digging in git history from ~2013 every few weeks, in an app which definitely runs and handles lots of transactions today. That code is not getting deleted any time soon and any explanations about the reasons in the PRs are extremely helpful. Understandability is great in this case.
Re: Code the shortest path first
#47I notice they link to The Pragmatic Programmer here: > If it’s a true greenfield project you are “prototyping”, if it’s part of an existing project you are making a “tracer bullet”. In the C2 wiki, someone paraphrases it like this: > In PragmaticProgrammer, they talk about TracerBullets in the context of building an ArchitecturalPrototype - a bare-bones skeleton of your system that is complete enough to hang future p…
Hi! Yes I couldn't find a better source, here's excerpting from the book-- "We once undertook a complex client-server database marketing project. Part of its requirement was the ability to specify and execute temporal queries. The servers were a range of relational and specialized databases. The client GUI, written in Object Pascal, used a set of C libraries to provide an interface to the servers. The user's query wa…
Great examples! We may have been doing it, but didn't have a name for it. More names is useful because when people say "prototype" or "PoC" they can mean many things.
Re: Code the shortest path first
#48Maybe I'm not senior enough, but I think this misses the point. If I'm not prototyping, I don't try to "code the shortest path first", I try to code using the most popular libraries, and the most concrete, broad-strokes, fundamental abstractions, towards a goal of improving understandability. At the end of the day, most code is deleted anyway. But even then people still need to understand it. I am attempting to write…
> At the end of the day, most code is deleted anyway. The timescale for that really depend on the project. I'm digging in git history from ~2013 every few weeks, in an app which definitely runs and handles lots of transactions today. That code is not getting deleted any time soon and any explanations about the reasons in the PRs are extremely helpful. Understandability is great in this case.
Yes, we value understandability if an application is succcessful.
My point was that even if logic isn't valuable understandability helps the person reading it decide whether to delete it or replace it. Code that can't be understood and sits within vast applications providing no value is often very difficult to remove and ends up being a long-term cost to a business.
Re: Code the shortest path first
#49Want to add that the shortest path is only obvious from hindsight. And someone's shortest path maybe shorter than yours. Incremental iteration seems all the rage nowadays, but it didn't take one's taste and experience into account. If one's shortest path is long and winded, no amount of iteration will bring you to any sorts of local optima. The ultimate judgement is whether the things you built is getting use. If a tree falls in a forest and no one heard it, it didn't make a sound. It doesn't matter your code is good or bad. Build a mental map that leads you to building things useful
Re: Code the shortest path first
#50Based on the context provided through the article, I think what the author actually wanted was a Minimum Viable Product, that is, instead of coding the shortest path first, you remove the need for unnecessary paths (and without cutting corners). This should create a reasonably correct product that is safe to use and easy to build on top of.
But I do agree about the CI/CD part. In my case however, it's because many of these CI/CD services uses their own propriety config formats which are unfriendly for local testing. I can't remember how much time I've spent on hot-trying Travis CI just to get the build process right. I imagine things could feel a lot different if the services supports NixOS or just Dockerfile based script, because I can at least try the script locally before invoking the online service.