process

How to become a better hacker

How to write innovative, unusual and simply cool software.

This is how I come up with my project ideas and implement them. Often other people think the ideas and the implementations are cool. A lot of times the software has the unusual combination of several tools "hacked" together. This blog post is about my personal process.

Why should you take my advice

I have some Boston github cred, and lots of projects published on NPM registry for example. Some of the notable ones are

Hope these projects and lots of blog posts have convinced you: I know how to create (hack) very unusual software.

How to do it

If you want to create projects like mine, here is how I do it

  1. I keep up with the industry. A lot of people complain about JavaScript fatigue: the number of tools, frameworks, libraries that appear every day / week / month is overwhelming. You don't have to learn and use the new tools, of course. Just be aware of their existence, and quickly skim the announcement or README. This will plant a seed of knowledge that will bloom later. For example, I looked at the Rollup when it came out, but I have not used it until I wanted to try tree-shaking as part of the compiled tool. A good source of industry news are email newsletters - they appear in your mailbox, have links, and can be quickly scanned for interesting stuff. I also follow people in the industry that post original content.

  2. Be part of the local community - like meetups and conferences. It is extremely important to listen what others are doing and talk to the speakers and other attendees. Ask questions, email your ideas, try to come up with interesting stuff that you might present.

  3. Become part of the open source movement. You should open source your own work if possible - a lot of code is just dead weight that cannot have business value. If Microsoft has realized it lately, then maybe it is time for your company to stop protecting things it cannot sell.

  4. Discuss technology and software libraries with coworkers - I cannot stress this enough. I am blessed (lucky, fortunate) to work with extremely smart and productive people. And they are the best resource for bouncing ideas, collecting feedback and support whenever there is some idea in my head. Of course you have to pay in kind: encourage others to develop new stuff, give honest feedback, and promote good ideas.

  5. Solve your own problem first. Most of the "crazy" hacks are just our production solution taken 10 steps too far :) Do not try to solve everyone's pain points - this will never work. Just try to come up with an actual solution to your own problem in the work place or in open source projects.

  6. Dream slightly bigger than usual. Whenever you solve a problem, see if there is something else that could be done - and it might be very unpractical, yet fork the project and try it. The beauty of GitHub is the simple repo forking - take an existing solution and build on top of it, all in a separate safe space.

  7. Learn new things outside your usual field. Attend the meetups not in your field! Read books on programming languages you do not see yourself using any time soon. Try "Hello World" examples in the unfamiliar environments. This will give you a taste of solutions that might be overlooked in your field; and the solutions can be ported across quite nicely.

  8. Try to connect separate pieces of software together. This has been a common theme among my projects: running the server software in the browser, wrapping a web framework to run without the "web" available, etc. A well designed software module might be useful in some new environment.

    This is also why I don't use type system like Typescript - it does not let me hack things together!

  9. Publish and describe your work. Even the smartest and best invention is useless without a good README, a demo and screen shots. By definition, if you have created something no one else has done before - you must describe it pretty well, since it is brand new! I found the moments of inspiration are fleeting, and if I delay the documentation / demo parts for too long, I will struggle later, trying to remember why I did this thing, and why this is useful (or cool). I like writing the blog posts, you might like code comments - whatever it is, describe it for yourself, but as if you were reading the docs a year later. This will force you to fill the details, and maybe write a better documentation.

  10. Do not expect much. Your batting average (the number of ideas that pan out) will be very low - you are making something new, after all. It is a risky effort; the thing might not even work, or someone else might point out a flaw that makes the whole thing useless. In my projects, without hard numbers to back it up, only about 25% of ideas are actually implementable, and less than half of the coded projects do what I expect. Thus only one 1 in 10 ideas survives and becomes something. Look at this number in positive light: you are aiming for things that are not very easy (and thus might actually be novel), plus your learned something from the other 9 failed ideas. In the next round, you can quickly filter out some of the initial ideas, increasing your success rate.

I hope this list helps everyone become better hackers, and write cool projects that would make everyone say "Wow".

If you have a cool idea, let me know, I love learning cool new tricks. Tweet / email me, and if I can be of any use, I will make time to discuss and give feedback.

Related and useful links

Last thought

The cool prototype, or hack project is just that - a prototype. It takes a long and hard work to make it production ready, or even portable and usable by others. Don't expect an experiment to be the top NPM downloaded project any time soon.