41–50 of 95 posts
Hands down: Taking on projects far beyond your skill level, and getting to the end of them.
One was to write a book about programming. Your programs literally have to be exemplary. It was interesting how much work that took.
That's a good example of how much you learn by teaching. To paraphrase Richard Feynman - That which I cannot teach I do not understand.
One was to write a book about programming. Your programs literally have to be exemplary. It was interesting how much work that took.
I currently work at a startup where I am the only developer. I'm also starting a company on the side where I am the only developer.
Does anyone have any advice on how I can supplement this? I'm currently looking into working on large open source projects, so I can work with other people, but I'm just not sure if that will work.
Started an extraordinarily ambitious open source project when I was just naive enough to not know better.
Mind if I asked why it was extraordinarily ambitious?
Also, my intention quickly became more than just a social networking app, and I really wanted to turn it into a framework for social apps. So that brought up all kinds of issues of MVC framework design and how to build an API and other large architectural issues.
Not to mention that a lot of the project I've had to do myself, with both very little precedence, and very little help (comparatively). Some of that was my fault, for not being better at documentation and project management, but I also learned that soliciting help for open source projects is a lot harder than The Cathedral and The Bazaar made it out to be.
It's easier now, that the groundwork has been set, and there are competing projects I can look at and learn from, but the first few years of flying blind was a hell of a crash course.
We also had to implement a subset of the bash shell, a lynx clone, a GNU make clone, a Lisp interpreter and a Lisp-to-C translator.
Having to implement many of the tools I've come to use on a daily basis was a transformative experience for me, and a great way to learn how to write efficient yet safe C code.
That experience inspired me to take the compilers class the next year, where I programmed in a functional language (Standard ML) for the first time. I was impressed with the expressive power and robustness of functional programming, and I've clung to it ever since.
These two experiences also set me on the path to becoming a professor. Now I teach and research compilers and programming languages for a living. I find hardly a day goes by where I don't learn something to improve my programming skills.
Not only does this help find bugs, it will force you to write code that isn't embarrassing. You will end up communicating much more with colleagues; before, during, and after the code review process. I believe it will clean up, or at least address, almost every bad habit you have.
If you can't get this at work, try an open source project that has a similar review process.
Instead of thinking, "How do I want this program to work?" I had to think, "How do I want every program to work?"
Instead of organizing this data, I had to organize any data.
Instead of worrying about what my customer needed, I had to worry about what to put in my toolbox before I called on that customer.
Instead of handling the current outlying case, I had to learn to anticipate possible outlying cases.
Instead of worrying about instances of what we do, I had to worry about classes of instances of what we do.
Instead of benchmarking and optimizing performance, I had to understand the kinds of things that affected performance.
Instead of scaling, I had to design an architecture that would scale.
Instead of conducting analysis and design, I had to build an application to handle and apply system parameters.
Instead of covering bugs, glitches, and inefficiencies, I had to eliminate them before they compounded exponentially before my eyes.
Instead of having fun, I had to build a world within which I could always have fun.