In software engineering there are two things you are trying to get right:
Software Validation - Did we build the right thing?
Software Verification - Did we build the thing right?
Software simplicity is a prerequisite to reliability.
A small, simple API is usually also a hallmark of a well-understood problem.
Make the code work I write is working. Then I can make it fast (if necessary). Solving the “correct/clean/performant code” problem all at once can be overwhelming. Don’t be overwhelmed. Solve one at a time.
Reducing the maintenance burden is, for most codebases, the biggest optimization I can do.
Of course it's all about striking a balance, but 99% of the time there is a choice between performance and readability, readability is the right answer. Performance should only be chosen if it is absolutely necessary.
If I write ugly code, anyone who intends to fix a bug or add a feature will not enjoy his work and likely avoid it next time.
Explicit over implicit is almost always better.
One of my principles is to always strive for simplicity when creating. In retrospect, I've learned many thing that I previously thought too complex to understand. The complexities tend to dissolve when you realize they are mostly just extra distractions emerging from the pressures of engineering the thing... distractions that you probably find yourself inventing all over again once you've assimilated the core idea.
Readme driven development is pretty neat. Write the README first as a specification. Then write the code for it. Zeit do it often.
We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes.
Always be looking for patterns. Abstract them always and only when it simplifies.
Persevere in getting an abstraction just right. When you find it, everything will magically fall into place.
The implementation is the design.
Hide whatever the caller shouldn't care about. In particular, you can remove type parameters with appropriate quantification.
Declarative configuration means that you write down the desired state of the world in a configuration and then submit that configuration to a service that takes actions to ensure the desired state becomes the actual state.
Every single feature makes product more complex, makes testing more complex, puts constraints on UI design etc. Controlling feature creep (also by revisiting old features) is very important to keep project healthy. Larger the project, more important it is.
“Simplicity” often just means that a concept fits cleanly in the maker’s head at a particular point in time. How many times have I returned to a project I thought was simple only to find I had burdened it with spooky magic because I didn’t benefit from critical distance at the time? When was the last time I deemed another person’s work “too complex” because I couldn’t understand it in one sitting and wasn’t aware of the constraints they were operating under? Answers: too often and too recently.
If we take a look at any given line of code in a method, we can nearly always categorize it as serving one of the following roles: 1. Collecting input. 2. Performing work. 3. Delivering output. 4. Handling failures.
The mindset that has helped me to improve my skills is that you should always just roll up your sleeves and look at the running process and its code rather than wasting more than 5 minutes searching for help or pouring over documentation that’s out of date and never correct. Put a short time cap on the time you spend doing that, and then just put on your explorer hat and pull out your scary toolkit to hunt that thing down.
Understand the business reasoning behind the project…look for ways of exploiting that knowledge to minimize the amount of work done.
Less code is always easier to debug…or if you can’t debug, throw out and replace.
Clearly defined project goals and constraints and milestones make development fast and visible.
Throwaway prototypes are faster than big projects and teach you more–and may be good enough for the business.
Understanding, deeply, the tools you use and the basic principles of computer science and engineering help you prune solution spaces a lot better.
Identify whether or not the framework/third-party app is actually delivering value over just implementing a smaller bespoke solution yourself. Color picker? Almost certainly. Database extension? Probably. Container orchestration for a static blog? Probably not.
Pseudocode and stepwise refinement of the solution to a problem. If you can’t explain something with bullet points, you don’t understand it, and if you don’t understand it, you’re slow.
Read, analyze and write lots of code. Don't be too concerned with the latest fads.
When I update dependencies, I generally try to check each update to see what has changed. This is where using a lot of dependencies becomes expensive, because it takes more work to update them. I don’t really see this process bring automated, unless a web-of-trust like thing got popular. But I’m not holding my breath.
Professional Programming - Collection of full-stack resources for programmers.
Awesome Roadmaps - Curated list of awesome software development roadmaps.
Visual Programming Codex - Resources and references for the past and future of visual programming.
Software Foundations series - Broad introduction to the mathematical underpinnings of reliable software.
Exercises in Programming Style - Comprehensive collection of programming styles using a simple computational task, term frequency.
Execute program - Programming lessons.
Best Practices Checklist - List of awesome idiomatic code resources. Rust, Go, Erlang, Ruby, Pony and more.
You don't need loops - Avoid The One-off Problem, Infinite Loops, Statefulness and Hidden intent.
Noweb - Simple, Extensible Tool for Literate Programming.
verso - New approach to literate programming.
Program Repair - Community-driven effort to facilitate discovery, access and systematization of data related to automated program repair research.
Design Patters for Humans - Ultra-simplified explanation to design patterns.
Learn With Jason - Live show streamed where Jason pair programs for 90 min to learn something new.
How to Design Programs - Introduction to programming and computing.
JetBrains Academy - Learn to Program by Creating Working Applications.
Awesome Katas - Curated list of code katas.
DomeCode - Single platform to learn to code.
Technically - Learn about software.
Computer Science Circles - Teaches computer programming.
All About Code Review - Curated collection of articles, tools, checklists and other awesome resources about code reviews.