Not a programming technique, but a mindset. If you separate your ego from your code ("My code doesn't define my value") then it becomes much easier to look at your code objectively and understand others' criticism. This allows you to grow faster and more openly (in directions you may have opposed before).
Ask HN: What change in your programming technique has been most transformative?
91–100 of 215 posts
Re: Ask HN: What change in your programming technique has been most transformative?
#92Programming in a team and accepting that it is not 'my' code but 'our' code. Not feeling slightly pissed when someone else changes the (not my) code. For me, this was a total game changer and a complete change in programming style. The focus changed to using the most common idioms, the clearest and cleanest and most concise way of writing stuff down, and avoiding smart hacks or, if necessary, encapsulating and docume…
I agree with the first bit; however it's hard to find a balance between accepting that your code can be improved, and standing by your solution. What I see in my team is that someone else has another solution, and whatever that is, should be implemented, if you argue against it, then it's often "I'm just trying to improve your code". However his solution might not necessary be better, it's just a different approach.
We also follow very strict style guides, but this is all defined in formatters and linters, so there's no arguing against it.
Even for my personal projects, the first thing I do is usually set up .editorconfig and TSLint (if I use Typescript).
Re: Ask HN: What change in your programming technique has been most transformative?
#93Continuous Delivery.
I'm building internally used software, and getting feedback from stakeholders in the testing environment was hard work, and often impossible.
We went from roughly monthly releases to deploy-when-it's-ready, and this tightened our feedback loops immensely.
Also, when something breaks due to a deployment, it's usually just one or two things that could be responsible, instead of 20+ that went into one monthly release. Waaaay easier to debug with small increments.
Re: Ask HN: What change in your programming technique has been most transformative?
#94Static typings + type inference Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... All libs/products should be pure functions, with input output documented, making libs/products predictable Use in-app event sourcing to reduce the need for global states states DoD https://youtu.be/yy8jQgmhbAU In non bare-metal languages, this will be useful for readability For errors, return instead…
Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found.
Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it.
Since then, I've wondered if that's what people mean by type driven development. It's cool to see that is at least in the general ballpark.
Re: Ask HN: What change in your programming technique has been most transformative?
#95Learning different programming paradigms. For example, logic programming with Prolog makes you think about solving certain problems quickly and efficiently in a declarative style. Strongly-typed functional languages like SML and OCaml make it easy to use types and pattern matching to reduce errors and shift some cognitive burden from yourself to the compiler. Lisps allow you to quickly prototype functions in the REPL…
Especially when using very general purpose languages often in business, I think what you get from learning completely different styles, structures and concepts in other languages is mental models for approaching problems that can help you write cleaner code, finding simpler solutions. When the choice is so broad (say you want to build a React App, there's 1000s of approaches, many of them only show their nasty side at a point where you now have a huge difficult to maintain app). I think some paradigms do lend themselves to different architecture too, and this helps you to discover more ways to architect code and make informed choices.
I found learning Rust valuable, as it forces you think about (and specify) ownership and mutability. It has exhaustive branch matching enforced by compiler, and it has no Null.
Also ChucK (and other niche languages are often cool). "ChucK is a concurrent, strongly timed audio programming language for real-time synthesis, composition, and performance"
I did a Coursera course on digital music creation in ChucK and it was such a joy, and such an unusual language.
Re: Ask HN: What change in your programming technique has been most transformative?
#96Voraciously eliminating unnecessary whitespace, especially vertical whitespace, was a trick I learned early. Most monitors are wide, not tall. When you can see a whole function without scrolling it's much easier to understand. I'll collapse 'if' statements to a single line in most cases to make it readable left-right instead of up-down. 1TB bracketing is my default unless style guidelines prohibit it. End-of-line com…
I personally hate one liners. I used to love them and feel good about how neat the code looked like.
After some time I've noticed that I read the code much easier and understand flow when the indentation is similar to python or go.
Also, I keep my editor on a vertical half of the screen.
Re: Ask HN: What change in your programming technique has been most transformative?
#97Self discipline. Just sitting down and showing up is not enough, you need to concentrate. This is why I think open plan offices are terrible for getting real work done, there always should be possibilities for solitude for those that need to work on something hard. Oh, and KISS. No way without that.
Re: Ask HN: What change in your programming technique has been most transformative?
#98Optimising for quick feedback loops.
Basically it involved writing additional code to set up the app state to the state I need.
It went from changing a line of code, running the app, clicking/filling fields as needed, and then seeing the change reflected, to the app immediately being in the state that I wanted.
Now that I'm working in web-apps, hot-reloading is quite beautiful.
Re: Ask HN: What change in your programming technique has been most transformative?
#99Recognizing that there's a special power in resilient technologies. Those that keep chugging along decade after decade, and getting stronger, too. Not from inertia or monopolist effects or other kinds of random lock-in. But because they tackle a certain set of fundamental problems very, very well. Despite endless complaints about their fundamental limitations, conceptual flaws or alleged lack of scalability. SQL, Pyt…
This is certainly not true. Evolution of programming languages is circumstantial . There are many flaws in all of the ones you had listed. The marginal cost of deprecating something or breaking something is higher than the incremental cost of workarounds. This happens all the time from the laryngeal nerve in Giraffe to the evolution of a programming language, say JavaScript. Please don’t mix good design with populari…
Look close enough and everything is flawed.
Evolution doesn’t ‘design’ anything, least of all anatomy.
The ‘special power’ is that they have stuck around, for whatever reason or circumstance.
Re: Ask HN: What change in your programming technique has been most transformative?
#100Something not mentioned yet. I find programming is the task of last resort and I spend a good deal of my time talking with the product person to help them refine their product idea into something that is mechanically sympathetic with how computers work and the general problem domain. It often adds 10% time for the initial work and -90% of the time for iterations. For example once we had a project that wanted to add R…
I would have used flags if roles aren't dynamic
in our case they were not only dynamic, but also managed by the administrator on an account (by our customers, not by us the software creator)