Ask HN: What change in your programming technique has been most transformative?

Programming in a team and accepting that it is not &#x27;my&#x27; code but &#x27;our&#x27; 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 documenting smart hacks. Not being shy of writing stuff multiple times until it really is clean and inviting to be read and understood. Using a very strict style (including when&#x2F;where to put white space and line breaks) that everyone else also uses so that code is easy to read for everyone. It improved my programming enormously and the bugs&#x2F;line ratio went down. It also gave a much better intuition to smell fishy code. It also took quite a while to internalise, but I now always code like that, also in private projects and in quick hacks scripts in, say, Perl.<p>My second most important change was to learn how to use contract based programming, or, if the language has poor support, at least to use a ton of asserts. This, for me, feels like stabilising the code very quickly and, again, improved my bug&#x2F;line ratio. It forces me to encode what I expect and the code will relentlessly and instantly tell me when my assumptions are wrong so I can go back and fix that before continuing to base the next steps on broken assumptions.

I would say: Automated testing and a functional programming mindset.<p>Even for legacy projects, starting with adding regression tests for every bug you find is a great way to introduce testing. And when you add new features, you can write tests for that as well.<p>I find that a FP mindset is helpful mostly because it tends to reduce the amount of global or spread-around state. This in turn makes testing and quickly iterating in a REPL a lot easier. Also when later the time comes to debug, it&#x27;s much simpler if you don&#x27;t have a huge amount of state to set up first.<p>And even if a lot of state is required, having it be an explicit input to a procedure is helpful because it makes it much clearer what you need to set up when doing manual testing.

It&#x27;s okay to be messy.<p>Treat code mess with the same techniques you would treat RL mess. Sometimes you sweep it under the rug. You can toss it in a closet or attic. You can buy a shelf or box and toss everything in there.<p>You can clean it up seasonally, like set aside a sprint for it.<p>Some kinds of messes are hazardous and absolutely should not be tolerated - this is similar to leaving milk out or trash piling. Many people make this mistake of assuming that because some messes are very dangerous, all of it is too.<p>Most messes will slow you down, but cost more to clean up. Overall, I&#x27;ve seen documentation do more harm than help - it&#x27;s often faster to interrupt a colleague doing something than for that colleague to spend weeks documenting and updating documentation on something that gets thrown away.<p>Some will take more time to fix later than now - this is what people mean by tech debt. But it&#x27;s less common than it seems.<p>With a lot of mess piles, the important parts float to the top and the less important ones sink at the bottom. God classes are mess piles.<p>Once the mess becomes a burden, it&#x27;s a good time to clean up.<p>You may need a few janitors and landscapers, especially for a large code base.<p>Some people place much higher priority on cleanliness than others. Be respectful of them but you don&#x27;t have to be like them.

Learning 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 and test them interactively, and thinking about code as data (homoiconicity) is a powerful concept.<p>In short, learning new programming paradigms completely changed my view of programming and these skills can translate over to more &quot;mainstream&quot; languages, so it is still a worthwhile effort.

You can come up w&#x2F; an algebra for a specific problem domain by thinking about the data models and repurposing some simple abstract algebra.<p>E.g.:<p><pre><code> new(state, &amp;args) =&gt; mutation apply(state, mutation) =&gt; state&#x27; </code></pre> Applied to finance:<p><pre><code> newPayment(balanceSheet, amount, date) =&gt; payment apply(balanceSheet, payment) =&gt; balanceSheet&#x27; newDiscount(balanceSheet&#x27;, amount, date) =&gt; discount apply(balanceSheet&#x27;, discount) =&gt; balanceSheet&#x27;&#x27; </code></pre> Applied to chess:<p><pre><code> newMovement(board, K, E2) =&gt; movement apply(board, movement) =&gt; board&#x27; newMovement(board&#x27;, b, D6) =&gt; movement&#x27; apply(board&#x27;, movement&#x27;) =&gt; board&#x27;&#x27; </code></pre> As a bonus, it&#x27;s clear where to enforce invariants and fail early:<p><pre><code> newMovement(board&#x27;, K, E3) =&gt; Illegal Movement (Can&#x27;t move to E3) newMovement(board&#x27;&#x27;, K, E2) =&gt; Illegal Movement (White King not available on board) apply(board&#x27;&#x27;&#x27;, randomMovement) =&gt; Illegal Play</code></pre>

Hot code reloading. It was one of the best decisions I made when I added it to a hobby project I&#x27;ve been working for the last six years. Most of my development time for this project is spent adjusting code while the app is running. The feedback loop is incredibly tight and the most engaging of all of the projects I&#x27;ve ever worked on.<p>I&#x27;m working on extending auto reloading to all of the assets in the project because I know that tight feedback loops are that important.

1. Using REPLs: The tool or the principle.<p>REPL means Read-Eval-Print-Loop and its a place where you can run code immediately and get immediate feedback. For example F12 in your browser and use the console to do 1+1. But you can also use that console to interact with your code in the browser, the DOM and make http requests.<p>But I also see REPL as a principle - to get as quick feedback from the code you write as possible, and things that help this are:<p>* Quick compile times<p>* Unit tests<p>* Continuous integration<p>So that each stage is as quick as possible. I write code and within as second or two know if it failed a test. Within a few seconds maybe I can play with the product locally to test it manually. Once committed, I can see it in production or a staging environment at least pretty quickly.<p>You can then have bigger REPL loops where a product manager can see your initial code fairly quickly, give you feedback and you can get stated on that right away and get it out again for review quickly.<p>I don&#x27;t think there is any excuse not to work like this given the explosion of tooling in the last 20 years to help.<p>2. YAGNI<p>Writing over elaborate code because it is fun! That&#x27;s fun at first but you soon learn it&#x27;s better to write what is needed now. There is a balance and writing absolutely shit code is not an excuse, but adding too generic code because of stuff that might happen is also a problem.

By far, starting to write automated testing as I code. The sheer number of bugs I find immediately and the number of bugs I find from changes that I didn&#x27;t expect would be enough to justify it, but what is even <i>better</i> is that it forces me to keep my code <i>testable</i>, which also happens to correspond fairly closely to <i>well-architected code</i>. Not perfectly, but for something that is automated and always running, it&#x27;s really helpful.<p>When I&#x27;m able to greenfield something myself, and use this from day one, I tend to very naturally end up with the &quot;well-separated monolith&quot; that some people are starting to talk about. I have on multiple occasions had the experience where I realize I need to pull some fairly significant chunk of my project out so it can run on its own server for some reason, and it&#x27;s been a less-than-one-day project each time on these projects. It&#x27;s not because I&#x27;m uniquely awesome, it&#x27;s because keeping everything testable means it has to be code where I&#x27;ve already clearly broken out what it needs to function, and how to have it function in isolation, so when it actually has to function in real isolation, it&#x27;s very clear what needs to be done and how.<p>Of all the changes I&#x27;ve made to my coding practice over my 20+ years, I think that&#x27;s the biggest one. It crosses languages. At times I&#x27;ve written my own unit test framework when I&#x27;m in some obscure place that doesn&#x27;t already have one. It crosses environments. It crosses frontend, backend, command line, batch, and real-time pipeline processing. You need to practice writing testable code, and the best way to do it is to just start doing it on anything you greenfield.<p>My standard &quot;start a new greenfield project&quot; plan now is &quot;create git repo, set up a &#x27;hello world&#x27; executable, install test suite and add pre-commit hook to ensure it passes&quot;. Usually I add what static analysis may be available, too, and also put it into the pre-commit hook right away. If you do it as you go along, it&#x27;s cheap, and more than pays for itself. If you try to retrofit it later.... yeowch.

Avoiding 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.

Functional Programming fundamentally changed the way that I solve problems. It also changed my expectations for how code should be designed.<p>The concepts that influenced me the most were immutability and the power of mapping+filtering. Whenever I read a for&#x2F;while loop now, I’ll attempt to convert it to the FP equivalent in my head so that I can understand it better.

Recognizing that there&#x27;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.<p>SQL, Python, PHP, JavaScript, and many aspects of Unix and the C&#x2F;Make toolchain all come to mind.<p>Mind you, I don&#x27;t <i>like</i> all of the above. At least 2 in particular I definitely wouldn&#x27;t mind seeing &quot;just go away.&quot;<p>But I do recognize that they have special <i>staying power</i>. And they didn&#x27;t get this power by accident.

Making debuggability (transparency) a first-class design criteria.<p>For many (most) systems, there are designs that make perfect sense, but will be hard to debug.<p>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 &quot;see&quot; the wrongness, my development time went way down--because it was really time spent debugging, so my productivity went way up.

For me it was three things: 1) learning to understand push&#x2F;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.)<p>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.<p>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&#x2F;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.

I throw away rough drafts all the time for non-trivial work that I don&#x27;t fully understand yet. There are different approaches to it, but I usually just create a throwaway branch to hack out a naive solution until I run into the non-obvious roadblocks and then try again. I used to try to _really_ understand something before coding a solution, but not being afraid of throwing away a rough draft has helped my mindset a bit in terms of working out difficult problems. It&#x27;s not a novel or huge concept but it works for me.

Static typings + type inference<p>Parse, don&#x27;t validate <a href="https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-validate&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-va...</a><p>All libs&#x2F;products should be pure functions, with input output documented, making libs&#x2F;products predictable<p>Use in-app event sourcing to reduce the need for global states states<p>DoD <a href="https:&#x2F;&#x2F;youtu.be&#x2F;yy8jQgmhbAU" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;yy8jQgmhbAU</a> In non bare-metal languages, this will be useful for readability<p>For errors, return instead of throw

&quot;Premature optimization&quot; was happening a lot more in my head than on the screen. By that I mean I would waste time struggling to succinctly generalize a function instead of making something work the easy and ugly way FIRST. It is far easier to copy paste working code in 4 places and leave a nice comment on each about what could be probably consolidated... without actually doing the work at least until you come back to the code to make a minor change in those 4 places. Half the time you never come back, most other times you end up merging them within a week. And for outliers... good commenting saves the day.

Some game changers for me off the top of my head:<p>* Automated regression testing and build&#x2F;deploy pipeline. The machine will do things quickly and repeatedly exactly the same way, given the same input conditions&#x2F;data.<p>* TDD. Create tests based on requirements, get one thing working at a time, and refactor with a safety net.<p>* Mixing FP style and OO style programming to get the best of both worlds.<p>* Understanding type systems, and how to use types to catch&#x2F;prevent errors and create meaningful abstractions.<p>* Good code organization, both in physical on-disk structure and in terms of coupling &amp; cohesion.<p>* Validate all incoming data and fail fast with good error messaging.

Many developers think of themselves as abstraction masters. &quot;Moar abstraction is moar better!&quot; Abstractions have a cost in readability and maintainability. It is very hard to make the abstraction that improves both. I&#x27;m tempted to say that pre-abstraction is a larger problem than pre-optimization.<p>Make your code easy to read at the expense of easy to write. Don&#x27;t abstract unless you know exactly the use case. If the use case is not immediately forthcoming, YAGNI (you aint gonna need it). Related, don&#x27;t be clever. Clever is cute and all. It does not belong in production code.

When working on most things, I ask two basic questions: how does it fail? how does it scale? I picked that up years and years ago.<p>Any line, function, workflow, etc can fail. You need to have worked through all the failure cases and know how you are going to handle them.<p>Somethings don&#x27;t need to scale, ever. But most things I work on do. If I don&#x27;t know the story on how I can ramp up an implementation a few orders of magnitude, then I can&#x27;t say I&#x27;ve designed it well.<p>Aside from that, measure everything. Metrics, telemetry, structured logging. Design for failure and design for understanding what happened to cause the failure. Data will tell you what you are doing, not what you think you are doing.<p>There was a post here yesterday about a neat map thing. I hit a bug and the author could only rely on their experience with it being potentially slow at times but saying it should work. If there were proper metrics in place, they would know that N% of calls exceed M seconds and cause a timeout. He could then relate this to the underlying API and its performance as the service experiences it. With proper logging, they see what the cache hit ratio is and determine if new cache entries should be added.<p>Build, measure, learn.<p>Oh, and automated tests. So much to be written on that.

Leaning on the type system for as many guarantees as possible. A few of my teams use Kotlin&#x27;s sealed classes and extension methods to prevent a lot of goofy invalid state and improve composability (using a Result&lt;T, E&gt; sum type very similar to what Rust has built-in).<p>I liked this article I recently came across discussing the topic: <a href="https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-validate&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-va...</a>

Continuous Delivery.<p>I&#x27;m building internally used software, and getting feedback from stakeholders in the testing environment was hard work, and often impossible.<p>We went from roughly monthly releases to deploy-when-it&#x27;s-ready, and this tightened our feedback loops immensely.<p>Also, when something breaks due to a deployment, it&#x27;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.

Optimising for quick feedback loops.<p>Basically it involved writing additional code to set up the app state to the state I need.<p>It went from changing a line of code, running the app, clicking&#x2F;filling fields as needed, and then seeing the change reflected, to the app immediately being in the state that I wanted.<p>Now that I&#x27;m working in web-apps, hot-reloading is quite beautiful.

Many incremental changes (some already mentioned here) but none comes close to grokking macros in Lisp and lisp-like programming languages such as Common Lisp, Scheme, Racket, Emacs Lisp and Clojure. That was truly, truly transformative.

Probably learning to use a debugger and decreasing my reliance on print() statements. It&#x27;s a nonzero initial investment but saves time in the long run.<p>At the team level, probably CI&#x2F;CD. It forces us to break the monolith into digestible chunks and makes regression testing easier.

I&#x27;ve recently joined a team that focuses massively on test-driven development, and it&#x27;s just such a great way to shake out dumb bugs and focus on the requirements and the problem you&#x27;re trying to solve.<p>Also recently did Thorsten Ball&#x27;s Interpreter&#x2F;Compiler books which focus heavily on unit testing the functionality (I can&#x27;t recommend these books enough).<p>I now can&#x27;t imagine going back to a pre-TDD world

Writing simple functions which take an A and return B in any context. Then, composing those simple functions together to build up more complex functionality.

Realizing that I can roll my own framework.<p>Why? Because I’ve tried to actually think about my underlying data structure instead of defaulting to convention but reflex.<p>The best example? Marcel Weiher Ch 13 in “iOS and MacOS Performance Tuning” explains how to improve lookups in a public transport app by 1000x.<p>What more? The description of the the data (the code) and the the application (the intended use) are probably way better because thinking about performance is similar to thinking about your data. You want answers fast. Fast answers, fast code.

I&#x27;ve been doing a lot of Python lately and using type annotations strictly and a decent IDE like VS Code or PyCharm. If you screw up, passing a foo instead of a bar, both almost immediately highlight the error. Don&#x27;t even have to run the script to see it blow up. Huge time saver.<p>Also doesn&#x27;t hurt that it improves Intellisense&#x2F;Autocomplete, gives better hints&#x2F;help as you&#x27;re calling a method, and improves on &quot;self documenting&quot; code.

I ask myself what&#x27;s the smallest, dumbest, least-coupled program I could possibly write to get the job done. Turns out that the answer is often &quot;very&quot;, and short, simple programs are a lot easier to produce bug-free and work with over time.

I wouldn’t be surprised if the majority here are doing this, but version control everything<p>Distributed version control is one of the greatest things to have gained popularity in the last ~20 years; if you’re not incorporating git, hg, fossil, ... start now.<p>You gain: concise annotated commits, ease of cloning&#x2F;transporting, full history, easy branching for feature branches or other logically seperate work, tools like bisecting, blame&#x2F;annotation, etc., etc.

I can think of 4 things:<p>1. Not being afraid to look at the code of the libraries that my main project depends on. It&#x27;s a slow, deliberate process to develop this habit and skill. But more importantly, as you keep doing this, you will develop your own tactics of understanding a library&#x27;s code and design, in a short amount of time.<p>2. Not worrying about deadlines all the time. Not a programming technique as such, but in a world of standups and agile, sometimes, you tend to work for the standup status. Avoiding that has been a big win.<p>3. (Something new I&#x27;ve been trying) Practicing fundamentals. I know the popular opinion is to find a project that you can learn a lot from, but that may not always happen. Good athletes work on their fundamentals all the time - Steph Curry shoots like &gt; 100 3 point shots everyday. I&#x27;m trying to use that as an inspiration to find some time every week to work on fundamentals.<p>4. Writing: essays, notes. In general, I&#x27;ve noticed I gain more clarity and confidence when I spend some time writing about a subject. Over time, I&#x27;ve noticed, I&#x27;ve become more efficient in the process.

Moving from my college years of emacs on the server to a proper IDE on the desktop.

Honestly at a team level - code reviews. At least one other developer reviewing every line of code that is written is transformative in the quality of code that is produced. A lot fewer problems, a lot more maintainable.

Autoformatting (gofmt, prettier, etc). I can&#x27;t believe how much time I was wasting having to manually indent, split lines etc.

Self discipline. Just sitting down and showing up is not enough, you need to <i>concentrate</i>. 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.

Can&#x27;t believe this list doesn&#x27;t include revision control systems. So many benefits. Without these, you can&#x27;t easily work with others. Never again break code then scratch your head wondering how to return it to previously working state (we&#x27;ve all been there). Have a documented history of changes over time. Support for branching. Also amazing for efficiency and not so frequently used are pre and post commit hooks for CI&#x2F;CD.<p>Basic inline documentation. Who wrote it, when and why. What else did you consider. How does it differ from other solutions. Why is it designed the way it is. Brief history of design changes. What state did you reach in testing. What are the forward looking goals. Takes 5 minutes, pays for itself many times over in future. 90% of effort is maintenance.

Immutability. I don&#x27;t use it all of the time. And sometimes I use bits of the knowledge I&#x27;ve picked up through playing with it. But encountering it made me think a lot more about how state is available through the systems I write, and that definitely made me a better coder.

Logger as an anonymous function.<p>I think literally every logger let&#x27;s you log at a certain point as a single line that does not cover the context of the log.<p><pre><code> logger.info(&#x27;Doing this and that&#x27;, function () { do_this() if(maybe) do_that() }) </code></pre> This way you know how much the log comment is supposed to cover as well as take a benchmark on the said context.<p>I can never think to just add a single line logger anymore.<p>This is much better than inserting comments in a code as comments can have no context except the line below.<p>You can add a function like,<p>logger.comment<p>and don&#x27;t let it log anything to be comment syntax replacement.

State Machines.<p>Thankfully that was decades ago, which means I enjoyed the magic and bliss for most of my professional career.<p>Also interesting: I started using state machines in hardware designs before I applied them in software.

Environment variables with fallback to a default value.<p>They&#x27;re a super cheap way of<p>1. allowing feature flags<p>2. injecting credentials in a way the user thinks about exactly once<p>3. moving workstation-specific details out of your code repository<p>They&#x27;re implemented into the core of most every language in existence (especially shell scripts) and you&#x27;re probably already using them without knowing. They&#x27;re (get this) _variables_ for tuning to your _environment_.<p>Sounds like I&#x27;m being sarcastic here (eh, maybe a bit) but it never really hit me until I really dug into the concept.

Honestly, I used to be such a computer nerd, to a fault. So over the last quarter century of programming for money, I&#x27;d have to say the most transformative has been writing comments like my livelihood depends on it (since it does).<p>Other development practices that boosted my output significantly: Regular cardio exercise like running, strength training by lifting weights, and regularly reading source code for pleasure.

Using <a href="https:&#x2F;&#x2F;github.com&#x2F;watchexec&#x2F;watchexec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;watchexec&#x2F;watchexec</a> to evaluate code as I save.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;nikitavoloboev&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;zsh&#x2F;alias.zsh#L15" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nikitavoloboev&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;zsh&#x2F;a...</a>

Async-await in Rust has made asynchronous programming a joy. It&#x27;s no wonder that programmers are refactoring as fast as they can to support it.

Not a programming technique, but a mindset. If you separate your ego from your code (&quot;My code doesn&#x27;t define my value&quot;) then it becomes much easier to look at your code objectively and understand others&#x27; criticism. This allows you to grow faster and more openly (in directions you may have opposed before).

Writing a basic test before starting a task, and use that to verify that the task is correct. I use the word task because this can apply outside of writing code, for example making some large scale changes to data. Never underestimate your ability to overestimate your ability. Reality is hard so make the machine help you.

Something 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.<p>For example once we had a project that wanted to add Role Based Access Control and some juniorish engnineer suggested adding boolean columns to the table for each of the user&#x27;s roles.. Nope. Instead we created a document store w&#x2F; roles and defining new roles was as simple as adding a const to a set in the service&#x27;s code. Good thing too because the number of roles grew from the initially requested ~3 to almost 100. That would have been too wide of a table.

1. Write notes, when notes can&#x27;t support ur thoughts draw, scribble. Date every page. Revisit the notes every 2-3 days. Put priority on the idea. Write notes when you about to get off work or before you go into a boring or interesting meeting and chances are you might forget what you were thinking.<p>2. Don&#x27;t get into the trap of refactoring just because you read a new cool way of doing it unless, it&#x27;s reduces half the size of code or improve performance multi fold. This might waste time as you could write a new feature or plan about it in that time.<p>3. Write very big elaborative comments. It&#x27;s for future you as you can&#x27;t remember everything, sometimes you need to know why you wrote that code or condition as you might not remember why you wrote it at that time.

If you have to run your code to understand it.<p>Try again.

Migrating from JavaScript to Typescript and declaring interfaces for classes and data structures forced me to put more thought into each piece before I start implementing. Now I’ve cleaned up a lot of old code I didn’t have much visibility over thanks to the compiler warnings.

Using static typing to make changes slightly bigger than intended.<p>But with a better architecture and nearly zero mistakes. Through using OO correctly ( please read the word correctly)<p>One step at a time.<p>Ps. This is mostly when a code-base is detected where a part of the code is sensitive for bugs. Eg. From today: handling better payment providers and payments.<p>I thought it was important enough to make the change bigger, but with the intention of removing recurring&#x2F;similar errors in someone else his code-base.<p>Afterwards, go to him and explain why. Developers can be proud of their code, although it&#x27;s just shitty code ( eg. Long functions, loops, if else, switch, by reference, ... Is mostly an example of bad code) and never say it&#x27;s shitty..

Off the top of my head:<p>- Reading books (e.g. Clean Code, Refactoring: Ruby Edition, Practical Object-Oriented Design, ... these left a mark)<p>- Going to conferences (Rubyist? Attend a talk by Sandi Metz if you have a chance)<p>- Testing (TDD at least Unit Testing)<p>- Yeah, the usual stuff: quick deployments, pull requests, CI&#x2F;CD ...<p>- Preferring Composition over Inheritance (in general and except exceptions :)<p>- Keeping on asking myself: what is the one responsibility of this class&#x2F;object&#x2F;component?<p>- Spending a bit more time on naming things<p>- Have a side-project! It&#x27;s a fun way of learning new things (my current one is <a href="https:&#x2F;&#x2F;www.ahoymaps.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ahoymaps.com&#x2F;</a> - I could reuse many things that I learnt also in my 9-5)

FP, REPL Driven Development and generative testing.<p>In short, I have been doing Clojure since last year.

I stopped doing small commits. In the past as soon as I was &quot;done&quot; with something I would commit, even if one line.<p>What would end up happening sometimes later in the day I would decide revert or modify the change, so my commit history ends up flooded with bunch of small commits.<p>I ended up writing a script that checks my current work, and if enough changes or time has past, then a commit is recommended:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;stvpn&#x2F;sunday&#x2F;blob&#x2F;master&#x2F;git-train&#x2F;git-board.php" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;stvpn&#x2F;sunday&#x2F;blob&#x2F;master&#x2F;git-train&#x2F;git-bo...</a>

I can&#x27;t think of a specific technique, but one thing that has been very useful has been exploring the use of fuzz-testing.<p>I&#x27;m pretty much adding fuzz-testing to all my current&#x2F;new projects now. It doesn&#x27;t make sense in all contexts, but anything that involves reading&#x2F;parsing&#x2F;filtering is ideal - you throw enough random input at your script&#x2F;package&#x2F;library and you&#x27;re almost certain to find issues.<p>For example I wrote a BASIC interpreter, a couple of simple virtual-machines, and similar scripting-tools recently. Throwing random input at them found crashes almost immediately.

- Letting code crash early and hard, deciding what parts of the code i never think about handling - Dependency Injection (ObjectOriented&#x2F;Functional), controlling when stuff gets created vs. used - Accepting to having some level of redundancy in code, using code to configure stuff (wrappers, adapters, factories) and not trying to pull out everything from the start - Figuring out what parts of what i could test i should test, being fine with just coverage - Writing a cli for every project - Learning how to transform code without breaking it for long periods of time

The most transformative experience was learning how to retain information better following the Coursera course: Learning How to Learn (<a href="https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;learning-how-to-learn" rel="nofollow">https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;learning-how-to-learn</a>)<p>I&#x27;d not always been the best learner and this taught me how to learn more effectively. Whilst at the sametime accepting the limitations of the brain.<p>It led me to find the Anki app and combined with more effective learning, it positively affected my ability to be a better programmer.

Voraciously 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&#x27;s much easier to understand. I&#x27;ll collapse &#x27;if&#x27; 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 comments make it easier to associate functionality with comments and keep code tidy.

A lot of really good answers in this thread. I had a great mentor years ago and she really taught me the importance of working cleanly and professionally. Proper code formatting, checking your comments for spelling mistakes, indentation, auto formatting on save, linting, writing solid documentation, rebasing and tidying up your commits to create clear steps that a reviewer can step through. All of the things that often get overlooked but are very important in how you come across as a professional developer.

Not mentioned yet<p>1) Start with consistent naming conventions, notation and structures<p>2) Rely on autocomplete to simplify typing&#x2F;readability&#x2F;programming effort. It’s a tremendous force multiplier.<p>Ninja’d<p>3) TDD<p>4) Functional programming

Touch typing. There was a huge difference in speed between the my brain and my fingers. Once removed, it was much easier to make the code flow.

A divide and conquer approach to complexity; which is turning the complex idea&#x2F;code into several loosely coupled simple building blocks.

I used to just write code fast and forget about it, only slightly caring about the finished product. After having to build and support 2 fairly large applications(for use on a company intranet) I will fully plan, document and test my software. No more clever code, no more quick hacks. I also gave up on Javascript and node.js, and I mostly do c# now because of type safety.

From iOS perspective changing to clean architecture using VIPER has made our code testable and easier to reason about.<p>We enforce the architecture as much as possible through protocol conformance, which doesn’t always work, but works extraordinarily well for “Views” or “Scenes”.<p>It’s taken so much stress out of the development lifecycle for our team.

A surprising one is to avoid all kind of jumps (early return, breaks and continues).<p>A broader one: writing expressions as much as possible. Basically, it means avoiding unnecessary mutations (and jumps).<p>Then avoiding architecture. Thinking algorithms that process data (instead of &quot;systems&quot;) has been transformative.

Being full stack in mind. You don&#x27;t need to have full stack skill, but you should have experience working on frontend, backend and Dev&#x2F;Ops. This can help how you design API between frontend and backend, how you implement your system to ease maintenance.

1. It&#x27;s better to implement solidly 8 features then partially implementing 10.<p>2. If you can, step through any new code with the debugger. You may find the execution path isn&#x27;t what you thought it was.

I program slowly now, and only program in my head and on paper. Only when I am 100% sure that I have something I can add as a small step to a larger working goal do I touch the code

Using &quot;this.&quot; for object-scope identifiers and &quot;ClassName.&quot; for class-level identifiers.<p>Greatly improved readability, even though there was a short adjustment.

Learning generics and the streaming system in Java. There&#x27;s a clear improvement in expressiveness and they minimize a lot of duplication and visual clutter.

Functional programming with functions as first-class-citizens. And related: asynchronous programming. Both with Node.js, a couple of years ago.

using data structures and parsing techniques over &quot;convoluted&quot; algorithms ( pretty much discussed here: <a href="https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-validate&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-va...</a> ).

1. Shifting from solo&#x2F;modular to team software development<p>2. Figuring out unit and integrations tests<p>3. Embracing clean code paradigm and SOLID architecture

Entity component system as a replacement of OOP. Don&#x27;t even bother writing a complex app without it.

TDD and clean architecture for me.

TDD for me. It&#x27;s frowned upon but has helped me craft elegant code with less bugs .

KISS + YAGNI + constant refactor. Code is a means to an end and I suck at futurology.

Metaprogramming in Common Lisp.

JSIO - just shit it out. Stop worrying about it being perfect and get it done

Learning ReactiveX. Never wrote classical imperative code since

start with explicit requirements to the system you are building. so obvious, but so neglected! i blame the typical belief in one&#x27;s omniscience.

two things 1) leading commas in SQL 2) RAISE an EXCEPTION or RETURN --no more `else` statements in code<p>SELECT this , that , something FROM table<p>takes a while to get used to

starting to use map, reduce, filter on Arrays, and arrow functions

Learning Doxygen

Buy oxycodone online, Oxy, sold under name OxyContin among others, is an opioid medication used for the treatment of moderate to severe pain. it’s usually taken orally, and is out there in immediate release and controlled release formulations From 24hrsonlinestore <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycodone-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycodone-...</a>

It is like instant release oxycodone, morphine, and hydromorphone within the management of moderate to severe cancer pain, with fewer side effects than morphine. Buy Oxycontin Online without prescription here legally.From 24hrsonlinestore. <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycontin-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycontin-...</a>

Buy Percocet Online without Prescription. This combination medication is employed to assist relieve moderate to severe pain. It contains an opioid (narcotic) pain reliever (oxycodone) and a non-opioid pain reliever (acetaminophen). Oxycodone works within the brain to vary how your body feels and responds to pain. Acetaminophen also can reduce fever. From 24hrsonlinestore <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-percocet-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-percocet-o...</a>

It is like instant release oxycodone, morphine, and hydromorphone within the management of moderate to severe cancer pain, with fewer side effects than morphine. Buy Oxycontin Online without prescription here legally.From 24hrsonlinestore <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-hydrocodone-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-hydrocodon...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycodone-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycodone-...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycontin-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-oxycontin-...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-percocet-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-percocet-o...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-ambien-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-ambien-onl...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-xanax-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-xanax-onli...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adderall-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adderall-o...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-dilaudid-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-dilaudid-o...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-lortab-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-lortab-onl...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-codeine-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-codeine-on...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-valium-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-valium-onl...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adderall-xr-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adderall-x...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adipex-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-adipex-onl...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-norco-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-norco-onli...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-vicodin-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-vicodin-on...</a> <a href="https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-methadone-online&#x2F;" rel="nofollow">https:&#x2F;&#x2F;24hrsonlinestore.com&#x2F;product-category&#x2F;buy-methadone-...</a>