two things
1) leading commas in SQL
2) RAISE an EXCEPTION or RETURN --no more `else` statements in code
SELECT this , that , something FROM table
takes a while to get used to
Ask HN: What change in your programming technique has been most transformative?
61–70 of 215 posts
Re: Ask HN: What change in your programming technique has been most transformative?
#62For me it was three things: 1) learning to understand push/pull between data structures and algorithms 2) learning new programming languages from different paradigms, and 3) understanding the physical implications of programming (i.e. latencies of disk-access, network, and memory; the non-amortized cost of pulling data from a database only to do the joins in memory, etc.)
My younger self did not truly understand the strength of modeling or treating data as the reification of a process. I saw everything through the lens of what I knew as a programmer which was, for the early 2000s java developer I was, a collection of accessors, mutators and some memorized pablum about object orientation. I treated the database with contempt (big mistake) and sought to solve all problems through libraries.
Now I can see the relational theory in unix pipes. I can see the call-backs of AWK and XSLT processing a stream of lines/tuples or tree nodes as the player-piano to the punch cards. I understand that applications come and go, but data is forever. I no longer sweat the small stuff and finally feel less the imposter.
Re: Ask HN: What change in your programming technique has been most transformative?
#63TDD and clean architecture for me.
Re: Ask HN: What change in your programming technique has been most transformative?
#64Making debuggability (transparency) a first-class design criteria.
For many (most) systems, there are designs that make perfect sense, but will be hard to debug.
When I started designing so that programs could tell me what they are going to do, what they are doing, and why, and so that their state, wherever possible, could be expressed into a structure where I could "see" the wrongness, my development time went way down--because it was really time spent debugging, so my productivity went way up.
Re: Ask HN: What change in your programming technique has been most transformative?
#65You can come up w/ an algebra for a specific problem domain by thinking about the data models and repurposing some simple abstract algebra.
E.g.:
new(state, &args) => mutation
apply(state, mutation) => state'
newPayment(balanceSheet, amount, date) => payment
apply(balanceSheet, payment) => balanceSheet'
newDiscount(balanceSheet', amount, date) => discount
apply(balanceSheet', discount) => balanceSheet''
newMovement(board, K, E2) => movement
apply(board, movement) => board'
newMovement(board', b, D6) => movement'
apply(board', movement') => board''
newMovement(board', K, E3) => Illegal Movement (Can't move to E3)
newMovement(board'', K, E2) => Illegal Movement (White King not available on board)
apply(board''', randomMovement) => Illegal PlayRe: Ask HN: What change in your programming technique has been most transformative?
#66Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.
Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the sa…
Sometimes you're lucky enough to have this expedited; my first CL at my first job was beautiful and elegant and concise and needlessly complex, and I was told to unroll it to make it more readable. The lesson sunk in the minute I had to start reading other people's code.
Re: Ask HN: What change in your programming technique has been most transformative?
#67Recognizing 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 popularity. It’s a correlation/causation fallacy.
Re: Ask HN: What change in your programming technique has been most transformative?
#68Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" http://www.linusakesson.net/programming/kernighans-lever/
Your link goes on to say that this doesn't mean the obvious. They say that cleverness isn't innate, and that writing code that you have trouble understanding later will force you to grow as a programmer
> If we deliberately stay away from clever techniques when writing code, in order to avoid the need for skill when debugging, we dodge the lever and miss out on the improvement. We would then need other sources of motivation in order to grow as programmers, and if no such motivation appears, our abilities stagnate (or even deteriorate).
I'm not experienced enough to guess if this is accurate, but I found it very interesting
Re: Ask HN: What change in your programming technique has been most transformative?
#69Earlier quoted context omitted.
Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the sa…
Sometimes you're lucky enough to have this expedited; my first CL at my first job was beautiful and elegant and concise and needlessly complex, and I was told to unroll it to make it more readable. The lesson sunk in the minute I had to start reading other people's code.
"Expedited" haha. yep. I mean there are times when something is going to cause just totally complex code to be required, but in those cases there should almost always be a full paragraph of "explanation" (documentation) for about every 10 or so lines of code.
Ends up with actually more documentation text than code itself, which is a good thing. But for the majority of code it an be kept simple and self-documenting.
Re: Ask HN: What change in your programming technique has been most transformative?
#70I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
How have you achieved a balance between too little and too much testing? I worked on a project that had a ton of tests, but they seemed to be "over fitted."
The trick is to get something covered to the point where you could comfortable refactor the bejeezus out of it, and know that it's still working from a higher level. The test should be how you know the code works, and under any situation.
That is, you don't need to test that inbuilt standard library stuff is working as expected (e.g does a string reverse) but rather, does the combination of possible inputs match your expectations?