Lots of content these days makes it easy to feel imposter syndrome and behind the times. What are you people who are actively trying to become a better programmer doing, learning, building or studying to become better?
The best way I’ve found to become a better programmer is to continue to practice solving real world problems (and see how other programmers solved them too). It keeps you focused with your time instead of wasting time on silly things like your tab/space size, white spaces, TDD vs. test first development, and all those silly debates that do nothing to add value to end users.
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.
In addition to this I think picking problems that you don’t immediately know how to solve but is within your wheel house is important. Also sticking with a single problem or domain. Constantly starting and never completing things doesn’t expose you to the next iteration of challenges.
With every project, I'm always learning something new. I went from building projects with dozens of files to less than 10 and try to keep it to just a single page. I went from spending months on projects to spending no more than a month on a single project, sometimes taking up to just two weeks to complete. I think it's the lessons of sticking to the logic and getting straight to the point with programming.
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.
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 :-)
Strongly agree. I often reach for pen/paper first and doodle a problem, just think about it deeply, poke at the shortcomings, think of scenarios where it might be inflexible, decide where not to over-engineer, etc before starting to write anything.
I really like your thought about cutting down the files. I find it’s a really good practice to write and make cheat sheets. This gets me into the habit of removing all the extras and try to get the core idea in a single file.
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.
I build things that I don't know how to build, mostly in C++ (because I like the language and I want to get better at it, especially the newer parts!).
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!
Continuing to learn advanced mathematics and revisiting core computer science concepts like networking, systems and architecture. Mainly from video lectures and O’Reilly books. Haven't tackled machine learning projects yet. It's one of my goals, but I must have a solid foundation first.
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.
I am trying to see if I can work on more interesting problems. Julia Evans has this great quote: "I have one main opinion about programming, which is that deeply understanding the underlying systems you use (the browser, the kernel, the operating system, the network layers, your database, HTTP, whatever you’re running on top of) is essential if you want to do technically innovative work and be able to solve hard problems."
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've been programming in JS for years now and only picked up clojure last september. I love it. I started with "Clojure for the Brave and True" and then went on to solve codewars challenges and make web apps in clojurescript.
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
Albeit not a programmer (but very much in professional IT), I find I "become better" not by learning a new technology, but by learning things tangential (or even totally unrelated) to what I do ... because it gives me new ideas / ways of looking at a problem / perspectives on what I do
I'm a so called "scientific" programmer. Yeah, one of those. ;-) A real software developer joined my team of researchers. By agreement, his job is not to be a code jockey for us, but to work on his own software related research projects. Still, I've asked him to watch what I'm doing and suggest ways to improve my skills. Meanwhile, he gets a guinea pig to try out ideas for what works in a research setting.
That’s a cool team setup! As a fellow computational scientist without much formal CS/SwEng background, do you mind sharing any insights you’ve found valuable so far?
One thing is that the members of the group all have different levels of interest in programming, ranging from None to Expert, even if we're not software developers. Just getting everybody to use Git has been beneficial.
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'll add one more thing while I think of it. You might be a good "lone wolf" programmer, but not good at working on collaborative software projects. Those projects are "big" because of team size, but also the expected lifespan of the code.
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. ;-)
I have been building Toph (https://toph.co), a competitive programming platform. I have been working on this for the past 7 years.
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).
1. My day job involves a lot of learning. (Learning DevOps, embedded Rust)
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.
I am learning to build a database from scratch and teaching people the same!
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
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'm writing an old-school ASCII roguelike game in JavaScript using the ROT.JS library. Games are interesting and give you a whole raft of puzzles to solve. Keeps me out of mischief and off the streets.
I'm trying to muster up the courage to pursue the realization of this multiplayer turn-based RPG that my friend and I dreamt up years ago. I lack experience with net-code and also large-scale architecture and also RPGs just have quite a large amount of game logic and it feels very daunting. I know how to divide the problem into smaller problems and I've made other games with non-trivial amounts of game logic but I still am struggling and I'm not really sure why. I feel a lot of anxiety when I look over my code for what to do next and then come back a week later (rinse and repeat). I feel internally that getting over this hurdle will be a large stepping stone for me.
I am building https://www.market.dev. I've learned about NextJs, Vercel, Supabase, Tailwinds, etc. These are the latest tools that have become popular. I can only learn these through side projects because in my day job, I work with an older stack, and it will take some time before we adopt to the new things. Another benefit of focuing on Web3, I can learn about the trend and what skillsets are more in demand in the new space. It's been a rewarding and interesting project. I also observed time needed to ship MVPs is much shorter than years ago.
I am currently trying to "push the limits" creating a small game engine using C++20 with modern libraries and tools. The goal is not to build a functioning engine or a game, but to see how far I can push things until they break, or get too complex, etc.
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.
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 work on contract Monday through Friday 9-5 as a senior lead developer, and I give them whatever they need.
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.
Yeah lol, it’s an early proof of concept based on the frontend and static content that I built out for Fillify.
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.
Doing small projects that exercice skills I am interested in one small step at a time.
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).
I start by asking Bing lately. Usually I have to use other resources too, but especially now that it has internet access I find LLMs to be a great way to start the learning process or finally learn about something complicated I've been putting off for years.
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?"
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)
My job at $BigTech (cloud consulting - application development ) allows us to open source any work that we do after going through a very easy open source approval process as long as it’s our work and we remove customer references. It’s licensed under the MIT license.
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.
I am studying system design as it relates to interviewing. I wish I could go back in time and study this consistently throughout my career.
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.
I've been doing this for over 20 years. I think my major leaps have been
- 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.
I’m trying out streaming on Twitch: twitch.tv/devtailsxyz
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.
I looked at my home architecture (home lab) and grew from 4TB to 1/4 PB in about two years, with a concentration on self-hosting and digital sustainability. I should reach a petabyte within 5 years.
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.
I'm the worst programmer when it comes to handling threads and parallel tasks in C++, that's why I'll read "C++ concurrency in action"[1] which has been recommended to me by a competent programmer.
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.
Who knows if it's a valid approach, but I haven't been too worried with chasing whatever's trending. Instead, I've been following a list of interesting potential projects I've written down. The list spans several platforms and several different types, so this takes me all over the place and should be enough to keep advancement rolling for a long time even if none of those projects ever leave the tinkering stage.
I’ve been working on building a web hosting platform.
https://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.
Building small projects with the small lessons I've been learning.
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.
Nothing specific. I already spend more hours than I'd like on my job. However, each day brings new experience and I think that adds value. I've learned enough languages/frameworks/stacks to know unless I'm going to use one daily, I'll just forget it so I don't bother with that anymore.
I'm subscribed to a few local mailing lists; occasionally someone will post something about a local theater troupe or artist's gallery needing a technical solution for a show they want to put on or exhibit they want to run, etc.
For me it's a couple weeks of Arduino prototyping and some Python glue, but for them it's the world.
I ask ChatGPT for solutions and see what it comes up with. It isn't always right when it comes to writing code, but it can be great with explaining things. At least I can check what it says with Google.
Looking at Erlang/Elixir to handle all distributed computing problems, J programming language for all mathematical/numerical computing (AI/ML etc.) and (Modern)C/C++ for everything else.
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 am experimenting with different software architectures, using code generation to see how much I can automate the software needed for new applications. I have learned a lot from this.
I’ve got some super talented programmers around me, however, they all use Clojure while I use Python as modelling tool. So I’m learning clojure right now
TDD tends to result in an encrustation of overly-specific unit tests that can make it harder to rethink a design as you go. It's a valuable technique, but can be counterproductive if over-applied unthinkingly. I've worked in more than one dev team that has imposed TTD-all-the-things policies they've had to retract.
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.
I definitely side with the people who said that what you are describing is bad TDD
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)
what imho. counts most in software-development ... efficient communication on all levels which is the means to an advanced understanding of the problem(s) to be solved.
for me, in a nutshell, software is the comprehension of the problem(s) at hand expressed in code.
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.