It gives you practice in mapping real world problems to code, by breaking the problems down into discrete chunks that can be independently implemented. It also teaches you how to design your code in a way that it can adapt easily to those real world problems changing over time. It teaches you where to abstract things out, where to be driven by configuration etc. It has to be driven by a real goal, not a made up one.
The other big thing, focus on readability over cleverness every time. Your code should feel easy to read even by YOU 3 months later. 6 months later. I’ve lost count at the number of times I cursed at my past self for writing some code where I thought I was being clever, but didn’t understand later. Mostly did that my younger years and then learned not to do that.
This is so important and something I had not realized until recently.
If there was anyone who helped me become a better programmer, it was my first tyrant boss, who was a complete asshole. I adopted his practices: write out what you want your program to do. What is its purpose? What does it do? How does it operate? Who will use it? Why? What will they pay for it? What will it look like? What pages will it have? Does it need these pages? And a bunch of other questions. It really helps to save a ton of time and keep you on focus.
He said to me: "You waste more time jumping into a program without direction than one where you spend a weekend just outlining what your program should actually do."
Really great advice that helped me write many programs.
He is an extreme proponent of writing very terse, compressed code in as few files as possible so as to enable him to read/mentally execute more of his program in a single screen/page and without too many context switches.
This is also the reason i always recommend to others to just focus on solving the main path in a program. Do what comes naturally and in as direct a manner as possible with no unnecessary distractions. This is the creative aspect of problem-solving. Don't bother about edge cases, exception handling, performance, design patterns etc. during this first implementation but just focus on meeting the specifications. This gives you a huge boost in Confidence and builds up Motivation for the next steps to make it industrial strength (only if needed).
The second step involves going over the first implementation with edge cases and exception handling in mind to make the Program Correct w.r.t. Specifications. The problem is now solved.
The third step is when you go over the second implementation and look to restructure/refactor the code with an eye to Modularity, Design Patterns, Best Practices etc.
The beauty with the above process is that, with time and experience the techniques in the second and third stages become assimilated and innate and now find expression during the first step itself! This is RPDM (https://en.wikipedia.org/wiki/Recognition_primed_decision) and you have now become a certified Expert :-)
I built a programming language as a library and put the entire process on YouTube.
I just recently built a job queue worker pool library.
Next, I'm going to tackle building a HTTP server as a library, hopefully supporting HTTP/1, 2, and 3.
Just build things that push your limits and enjoy the journey!
Never thought about building things to become a better programmer but to create something exciting or cool. Nowadays, it's mainly personal iOS and Javascript projects.
My using snowflake on the job made me more curious about modern analytical databases, so much that I want to get more into the internals. I am on a journey that's making me read more about database internals, take free courses online, and this in turn is leading me to some auxiliary things I need to know for knowing about databases, like cpu architecture (cache handling, branching etc) and further down the rabbit hole. To some extent, it's helping me overcome the feeling of inadequacy due to not having a computer science education even though I have been in the software field for more than a couple of decades. Not that it has harmed me much - I have always felt that you could learn things on the job in software development. But it just feels somewhat right to go back to the basics.
As someone with most of their experience in JavaScript and Ruby, I really like how Clojure is just so _different_. It's like someone who speaks English learning Chinese instead of a similar language like Spanish. I think doing that opens your mind and teaches you more than if you learned something that is "more of the same". Similar to how it is useful to learn about other fields instead of continuing to grind away at "more of the same" within your field.
I completely agree with your point about learning something different. Clojure is really good at handling immutable data, lazy evaluation, macros. So you can write elegant code that would be inefficient/unweildy in something like js or python
It's OK to start out with dirty code. Within a tight team, it's OK to make breaking changes if you warn people and help them fix their stuff. We have just begun to adopt a discipline where nothing leaves our group if it's not in decent shape, and this is going to include testing. In fact, I just took an online course on unit testing, and have applied it to a small library for the first time.
You can see that we're really starting at the ground floor.
At the present time we don't expect our code to be directly incorporated into the production code base, and in fact we use a different language. We're in an experimental group, so we're interacting with physical equipment, and our software guy has asked us to start including simulators so he can work on stuff from home. This is good discipline anyway because it lets us run our unit tests without all of the hardware connected.
I've noticed that the developers love layers of complexity and abstractions. Us normies, not so much. Keep things simple if possible. I've been moving to a more functional style, not due to thread safety but just the ages-old warning against using global variables. A big unwieldy parameter list is preferable to fetching parameters from globals.
We comment our code. I'm skeptical that comment-free code documents itself. At the very least. Scientists tend to be OK at explaining themselves in text, but doing so in code involves a learning curve.
I've been asking for some mentoring on how to manage a shared project, where more than one person is modifying it. For instance, learning how to handle things like pull requests and merges, rather than just using git as a backup drive. I'm still at the front end of the learning curve on that.
I already know that there's a tradeoff, just from being adjacent to a real software team: Software product development is painful to watch because it seems so slow and bureaucratic. And OMG the meetings on top of meetings. But the devs have to strike a balance between reacting quickly to changing needs, and maintaining their sanity over lengthy project lifespans.
The devs think what we're doing is painful to watch too. ;-)
The stack includes Go, MongoDB, Redis, RabbitMQ, etc.
Not only have I been gaining software engineering skills, I am also learning aspects of business and growing a community.
I am doing this, of course, beside my client work and open source projects. And, fortunately, my client work tends to be interesting enough and provide opportunities for learning new stuff almost all the time.
I don't know if it is true for everyone or if I am phrasing this right, but keeping myself busy actually building something/anything helps the most (instead of just chasing whatever is new out there).
2. I write open source software in my spare time. (Learning WebAssembly, reactive programming)
3. I learned and mastered a functional language, learn DSLs and make compilers for them.
I'm allowed to work professionally on stuff that's new to me and my employer.
The interplay with "getting stuff done" at work and "perfecting the craft" in my spare time is an attempt to strike a balance: Think about the design, leave things nicer, but don't spend forever.
Learning and mastering a functional language makes you think of programming patterns. Studying the programming patterns of well-made open source Haskell and Rust libraries has had a big impact on my learning.
It taught me how to take on a daunting subject, break it down and make it approachable for beginners. I learned how to reduce the initial friction so that it is effortless to get started.
I set it up in TDD style so you always get quick feedback, and it guides you in the right direction
python version: https://github.com/avinassh/py-caskdb
go version: https://github.com/avinassh/go-caskdb
Despite all of the FUD about how it would impair learning, it lets you skip through boilerplate you already know how to do, shows you some ideas you wouldn't think of, and can work as an on-demand code reviewer.
I recently discovered how good mimalloc is, how helpful tracy integration is, and that static reflection is actually somewhat possible in modern C++ thanks to refl-cpp.
And a lot of other, domain related things.
For me, pushing the limits, and just building things definitely contributes a lot to becoming a better programmer.
Nothing.
I'm 10 years into a stagnate career. Just going to wait it out another 20.
A cellular automata runner where you can define the rules and watch what happens: https://aperocky.com/cellular-automata/
Browse THIS website in terminal: https://github.com/Aperocky/hnterminal
A random simulation of prehistoric civilization and market: https://prehistoric.tech/
Every few months I get a bubbly idea and start some fun project, and they are usually small enough I get to finish them in a week or so, package them either on the web or pip/npm. It feels like a boost to software engineering as a job, which can occasionally get boring.
I start checking out around 5 and wrap up for the next day. Then I hang with the family and try to have a chill evening where I can detach my brain from the code I wrote earlier in the day. Once everyone has gone to bed, I like to fire up my personal laptop and work on side projects or whatever until like midnight.
I lurk in developer Facebook groups and subreddits daily, and watch YouTube videos on any topics I need help with.
Recently I’ve been working on a little open source side project that is a cool frontend developer tool for building react apps. It’s based on an email conversation that I’ve had with dang, and I plan to do a Show HN soon to get more feedback.
Git repo’s in my bio.
I reversed engineered the tools they used to build out the beautiful content at plausible.io last year, and now I’m turning it into free tool for frontend developers as a passion project.
These days it is a lot of LLM as it is a moving target with a large number of applications (they are the perfect toy to go quickly from "I wonder if I can do that" to a working prototype).
It's especially good for the kinds of questions you would normally need to know someone personally to ask.
"I don't know anything about this programming language but I'm interested in learning it. I know python pretty well. Can you explain the fundamentals of the language and how it is similar and different to python? Below that, can you write some code examples in x language and in python to show the difference?"
Stuff like that.
Currently working on Writedown: https://writedown.app - https://github.com/NayamAmarshe/writedown
I wanted to create a note writing app that supports markdown and has sharing capabilities. I usually use a Telegram private channel for saving stuff and writing notes, but Telegram doesn't really support Markdown so I thought it would be a good idea to create something like that.
Writedown is currently a WIP and I'm building in public (doing nothing special, just the repo is public haha)
When I open source anything, it forces me to practice being a better technical writer since I have to document everything. I have to explain why this piece of work should exist.
I’m more concern about the general applicability of it and is my code clean and well presented.
Just knowing that my work is out there for the entire world to judge gives me a level of discipline.
No I don’t do any of this outside of work unless I’m really bored.
Why? 1. I am not good at verbalizing the details unless I read or practice the concepts periodically, even though I grok the main concepts due to past experience.
2. Last 10 years has been a boom in horizontal scaling. I just learned what a MinCount sketch is and I did identical work in this space back around 2015. Designing Data Intensive Applications book was published in 2017 but I recently bought it.
3. Not all of us work for FAANG companies and don't always get to work on scaling problems. I find them fascinating though and fun to work on. Studying about it and doing a small side project is a great way to learn.
4. Money. There is a better chance of landing a role at a FAANG company with top pay if you can ace the system design interview and coding (leetcode) interview (at least before the recent downturn). Or a higher pay at 2nd tier tech companies by coming across as more senior.
5. Learning and growth mindset. I spent too many years at working chasing results and learning as I go, but not enough time in stepping back and investing in my training in areas (see above) that are very important but not very urgent. System design resources are plentiful and free, and it's easy to find good resources if you search via the lens of interviewing.
I've always been a little overwhelmed with the amount of new software/cloud tech that comes out and not choosing to start somewhere (unless my job at the time called for it). I've personally found that looking through the lens of finding a new job provides accurate and motivating results. Even if it's not studying system design, you can at least find out the hot skills by looking at senior/principal software roles. Aside from machine learning, I keep seeing AWS and Kafka on the list of tech aside from the normal python+linux skill requirements. And while the tech skills may change quickly (it was cassandra and rabbitmq back when I remember), the concepts in Designing Data Intensive Applications provide core foundations/understanding for a lot of depth in systems.
- Contracting. New workplace approx every 2 years avg, I got to work with some really talented people which I sought to spend my time with as much as possible and learn from them.
- Personal project. I may be contracting on .NET but geeking at home on Python. I may be contracting on PHP but doing SwiftUI at home. I make games, software, tinker on other stuff. Basically widen your scope, explore by doing.
If you want to be in the top 10% of any field, the key is to be willing to go further than 90% of the field. And the beauty of this ever-changing industry, is that you have no idea where that's going to lead you.
Mainly focused on learning rust while streaming. Streaming forces me attempt to explain what I’m doing which often shows me what I don’t properly understand.
Ultimately I had a poor grasp of what scaling compute effectively looks like, but I feel much more useful when working with cloud resources due to better foundational understanding in that time. It all started with me putting too many services on one server, and everything webbed out from there.
I think it's going pretty well so far, has gotten me in the door at my last two jobs.
Also a friend of mine asked me to write him an application for his business. I'll it as a challenge to learn Qml, SQLite, and CMake/Conan.
[1]: https://www.manning.com/books/c-plus-plus-concurrency-in-action-second-editionhttps://github.com/symkat/MyJekyllBlog - It’s centered around hosting Jekyll blogs. It supports having paid user accounts (Stripe), building sites (uses podman containers), deploying built sites to web servers, obtaining SSL certificates for the sites it hosts.
It’s been really fun to work on.
Studying design patterns and broader concepts - Gang of Four, Bob Fowler, Casey Muratori, Yegor Bugayenko), programming languages (OCaml, php, Java, C), and frameworks (Laravel, Django, Rails).
It's been a long and glorious slog. But it's like learning a language: the more you speak and write, the more you can speak and write.
When I find myself feeling like an imposter with X technology, I build a small project with X.
This pattern has helped me build the confidence that if I don’t know X, I know I can figure it out.
This is what I am currently planning https://sijinjoseph.com/programmer-competency-matrix/
For me it's a couple weeks of Arduino prototyping and some Python glue, but for them it's the world.
2) Trying to improve foundational skills like creativity (produce better ideas, more ideas, or ideas faster)
in general: small, bit-sized projects that solve a problem i have or something that has been on my mind for a while
2) Dive into AI, learn how to do small scale LLM end-to-end experiments
3) Pick up my game experiment on Heirarchical Task Networks, based on Maslow's Hierarchy of Needs.
I'm managing my resources with Terraform - I'm about to start managing all my personal GH repos this way too! I think GitOps and DevOps are cool and a great way to level up as a programmer.
And I'm doing a master's in CS through UT Austin, focusing on machine learning. Implementing old and new architectures in PyTorch.
Last, I'm building an "embeddings as a service" app, which is mainly just normal full-stack stuff but hopefully will present some complexities as we go.
I also try to complete a small personal project every month and write about it.
- TDD - Clean Architecture
That's what I am currently learning.
Not that they aren't worth learning, of course!
Clean architecture as a goal is, of course, uncomplicated. It being a good thing is assumed in the term "clean". However, it is often only one of a set of competing goals and in practice sometimes genuinely has to be sacrificed in favour of hitting a deadline. Spending a year designing a beautiful cross-asset trading application for a new hedge fund is not much point if, in the meantime, the hedge fund goes bust because it can't trade.
These are both trade-offs. TDD reduces flexibility (there are purists who will say you're doing it wrong if that's the case, but in that case pretty much everyone does do it wrong and that in itself needs to be accounted for / traded off). Clean architecture can require more time/resources than a "dirtier" approach to achieve a specific short term goal, and that short term goal can genuinely be more important.
I'm not arguing against either, of course. They are both important and you should learn them. But an experienced developer learns that everything is a trade off.
This is the result of people believing « unit test » means I should only test one « unit » (usually a function)
When you start testing a behaviour which can span multiple scopes, your tests don’t suffer from the same problems.
As for Clean Architecture, the overhead is quite minimal, and being able to hide complex stuff behind an interface means you will actually save a lot of time (like not having any database for several weeks, which helps iterating a lot quicker)
I have had the chance to see strong craft practitioner, it convinced me that they are indeed faster than the majority of developers (and ship more often)
You have:
- Head First Object-Oriented Analysis and Design, and
- Head First Design Patterns.
for me, in a nutshell, software is the comprehension of the problem(s) at hand expressed in code.
It sounds to me as a perfect language for SIMD?
RTFM. Constantly.
I think the same applies here.