Ask HN: What are you working on to become a better programmer?
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?
94 comments
[ 1.8 ms ] story [ 193 ms ] threadCurrently 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)
You have:
- Head First Object-Oriented Analysis and Design, and
- Head First Design Patterns.
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.
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.
It’s been really fun to work on.
I think the same applies here.
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.
See also : https://news.ycombinator.com/item?id=32202742
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 :-)
For me it's a couple weeks of Arduino prototyping and some Python glue, but for them it's the world.
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.
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.
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.
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).
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 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!
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).
in general: small, bit-sized projects that solve a problem i have or something that has been on my mind for a while
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.
- 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.
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 sounds to me as a perfect language for SIMD?