If you don't come up with a NIH project to keep you busy, someone might realize you're superfluous. Time to start another internal tool project! Or maybe a full architecture remaster. I hear Golang is hot right now
On the subject: What is a good, idiomatic, Go project to study? Something big enough to be a good example of code organization, yet small enough not to become a new hobby.
Well, then go on - list your interests (or skills).
And please don't pick a project that's desperate for people -
It's a classic case of the mythical man month.
Most of the time the core folks will find bringing up a new member up-to speed as a distraction, particularly when there's no commitment from either side to keep working on it (compared something like google summer of code).
PS: if all else fails, pick up a new programming language & write examples/cookbook-recipes for it
I tell people to build a small crud application that you can use to manage some data you have some interest in. I've build a similar non-marketable applications, usually a todo/project management application or something that imports a bunch of stock market data probably 30 times now, I actually use the project itself to learn new languages and frameworks because it hits most of the areas I will have to learn to be productive and I can pickup the language semantics along the way. When you're done you have code that is going to be doing things you will actually encounter in the wild instead of contrived and isolated examples from text books.
My favorite part is once I'm done I feel comfortable enough with reading through repos and some books over how to be more efficient/idiomatic and then going back through my little project and refactoring it.
With all that said I have a graveyard of projects in languages and technology that is probably not used anywhere commercially and the project itself is languishing if it was completed at all - but for example, I have a half working todo app in racket and despite being a junk app in a non-commercial language, I had to learn lisp and it at least subtly has influenced how I approach problems. Same thing with Rust which I actually use quite a bit personally and commercially, but when I originally learned it I was 100% golang professionally and I noticed my golang functions would resemble rust functions if I squinted and I think the complexity in my golang went way down.
I guess my advice is Just Start Building Projects (that you may never even show anyone or post on github, much less go marketing it.) and you will benefit from it massively. If you are able to learn and benefit from it _and_ it becomes popular or a commercial success than great! But who cares, on the internet no one knows you aren't a dog.
I love to do small projects even if they technically don't finish. Sometimes those are useful later down the road when I am working on a bigger project and that little project comes in handy. For example, I just created my own poor man's CMS in Go that processes Markdown to HTML. A while ago, I had played around basic Go library that does that so I just used it easily in my project without needing to spend too much time figuring out that library.
Ive started 3 projects i would like to come back someday:
1) HoM&M3: Hota player vs AI battle simulator - i already did some reverse engineering of AI used in battle and reimplemented some game mechanics to be able to run simulations with a few units. Purpose: to find average best possible output for given fight scenario.
2) Benchmark runner, database and visualization - i have some code for db, cli and dsl used for querying data. Purpose: to find performance regressions in subsequent builds and to give nice visualizations of product performance for management and marketing.
3) General purpose scripting language built in Go. No code, but most of the grammar already defined. Purpose: mostly educational.
Short projects are an excellent way to learn a new tool or framework. Want to learn Next.js? Looking for an excuse to try that new Golang game engine? Pick an obscenely small goal and you'll likely have more fun exploring the docs and learning the tool than getting stuck in the weeds of the myriad requirements not helping you learn that new tool.
Projects can sometimes be just for fun. I started with two goals: 1) Learn how Erlang internals work 2) Learn Rust (this was the first time I was writing Rust)
After I achieved both of those I decided I'll keep going if there's any interest in the project. There wasn't, so I moved on.
I have three side projects now. One of them (active) keeps expanding and it might be fair to call it a program instead of a project. It has had a large aspect of discovery; often when I try to invent a new feature I go on a long detour that involves discovering the nature of the system, once that has been unveiled the actual invention and creation seems almost trivial.
Project #2 has an early prototype but there is no energy going into it because #1 is in a state of ferment.
#1 and #2 are prerequisites for the social bit of #3 which is frankly a moonshot.
Really I don’t add new projects often and I rarely let a project be motivated by ‘learn a new language’, ‘learn a new framework.’ Often those are just black holes. Go learn LISP or Haskell and you will either fail to learn it and still think the grass is greener over there or if you really do learn it you realize that ‘a monad like is like a burrito’ is the definition of insanity and there is a good reason why people dream of LISP and Haskell and really write C, COBOL, ColdFusion, JavaScript, whatever.
Sometimes my projects force me to learn a new tech and then I do it. I am looking forward to WebGL.
Sometimes it's good to give them a repetitive project where you give them one task and have them repeat it. I once trained an intern to do molecular biology from basically nothing, he made 50 mutants and tested 25 in three months. He got a publication out of that.
On the other hand, I have an intern now, who I've taught go (she made a cli and learned tdd) and had her set up a tensorflow deep learning pipeline, which is not repetitive and very exploratory.
More software? Wonderful! I'm all for it, but before starting something from scratch why not contribute to something that already exists, or possibly pick some project that was abandoned or simply needs to be worked on for example to be built with newer compilers, run on newer hardware, etc. Which makes me wonder if there is somewhere a database of dormant/dead projects that would deserve to be resurrected.
If I had six months free, I'd focus on one or more of my existing side projects.
- The big one is my laser cutter. I've got the low level software stack mostly finished, but I want to use it as a vehicle to learn about web programming and user experience.
- I am learning to program FPGAs. I still haven't identified the project here, but i'm leaning toward a CPU with high level language support or video processing.
- I've written Scheme interpreters, but I'd like to write a Scheme compiler. This could be combined with the FPGA project. I'd also like to use Scheme (or Clojure) to develop a large project or two.
I have side projects in JS and TS (Node.js), Python, C (~500 loc projects). Mostly I care about solving a specific problem. Learning a new stack just so I can put it on my resume would require time I don`t have :(.
I've spent most of my career doing systems level programming on distributed systems. I have a strong language preference for C and Go.
I'll be leaving my job soon and if I work on anything over the next couple of years I want to own my work - even if that means giving it away for free.
I'd be interested in working on something from almost any domain (IoT, blockchain, ML, data stores, protocols, serialization, ...).
reply