Not that many years ago, though more than I care to remember, the process of writing code started with pen on paper. I’m not talking about 1970 here where you had to apply for compute time on some mainframe to see your ideas come alive, rather 1995 where it seemed the normal practice was to encouraging us disobedient students to first distil our ideas (and code) on paper. I’m gathering that this practice is largely forgotten? Despite its disappearance this can still be good practice but is made difficult by the increasing complexity of modern code libraries and frameworks.
Take Ruby on Rails for example. This used to be the poster child of getting an application up and running quickly. This might be still be true if you have years of experience developing Rails applications but for a newbie, forget it, you are going to struggle. The introduction of the asset pipeline, amongst other things, has made learning how to use Rails a labour of love.
It’s not just Rails though. A lot of the code that you need will already be wrapped up in a library written by someone else. Creating a modern software application is essentially just a case of rearranging these packages into a new unique order. In fact, the need for the order to be unique can probably be dropped.
Using these libraries is good though? Right? I mean we should never “reinvent the wheel”?
So how many times do you find yourself spending more time trying to figure out how the fuck to use some library than if you had written it yourself? No-one really expects there to be detailed documentation, which is just as well, as in general you’d be thoroughly disappointed. Maybe it’s because I’m dumb, but figuring out how to use a library can be a complete time sink. I mean, I hate to encourage this, as it seems like I’m committing a heinous crime, ’cause that’s what I’m told I’m doing, but just write the code yourself if it gets it working quicker for you. Obviously don’t rewrite the exact library that you are shying away from using, that is just stupid, but if you only need a subset of it’s functionality then go for it.
Never forget though, there will be a team of astronauts telling you that’s not what you should be doing. They will be spouting dogma, about this and that. However, if abandoning some well written (and not so well written) rules allows you to create a product that people use and love then tell the astronauts there are people who want to hear their shit on the moon and let them go there.