4 ms·

As someone who never went to grad school: how would a software consultant or freelancer approach this?

nostrademons 7y ago
You should at least search Google, GitHub, Maven, NPM, etc. for libraries, SaaS vendors, or published algorithms that do what you're attempting to. "The best line of code is the one you didn't have to write." Though there's a fair bit of subtlety in using them. There's nothing quite as bad as finding a framework that does 95% of what you want it to and will save you years of development effort, building your architecture around it, then getting 80% into development and finding out that there's no way to make it do the remaining 5% reliably and its developers have abandoned it precisely because of that shortcoming.
peatmoss 7y ago
Most times I wouldn’t say it’s important that you go through exactly the same formal process that you’d do if you were planning to publish your own peer-reviewed article. However, in a software engineering context, let’s say that you’re implementing a new library to do something in a new programming language. If other, more established languages had popular libraries that did something similar, I’d systematically catalog what those libraries are, read their user docs, maybe read their source a bit, and certainly try to develop an understanding of what I thought was the right approach. In your own readme, including this information up front, along with why you chose to implement the way you did almost certainly advances the state of the practice. At a minimum you’ll have a record of what influenced your thinking so that, if you come back in the future, you’ll know what other threads may have advanced in the meantime. I’ve thought of this as a way to contribute to open source that isn’t writing code or docs after the fact. Like, imagine you’re a Racket user and you wish there were a library to do X: maybe it’s a worthy contribution just to start a github repository and document the libraries that do something similar, and what you see as good and bad about those approaches. Maybe someone with the bandwidth to write the software will see your documentation and find that it gives them a head start.

You should at least search Google, GitHub, Maven, NPM, etc. for libraries, SaaS vendors, or published algorithms that do what you're attempting to. "The best line of code is the one you didn't have to write." Though there's a fair bit of subtlety in using them. There's nothing quite as bad as finding a framework that does 95% of what you want it to and will save you years of development effort, building your architecture around it, then getting 80% into development and finding out that there's no way to make it do the remaining 5% reliably and its developers have abandoned it precisely because of that shortcoming.

peatmoss 7y ago

Most times I wouldn’t say it’s important that you go through exactly the same formal process that you’d do if you were planning to publish your own peer-reviewed article. However, in a software engineering context, let’s say that you’re implementing a new library to do something in a new programming language. If other, more established languages had popular libraries that did something similar, I’d systematically catalog what those libraries are, read their user docs, maybe read their source a bit, and certainly try to develop an understanding of what I thought was the right approach. In your own readme, including this information up front, along with why you chose to implement the way you did almost certainly advances the state of the practice. At a minimum you’ll have a record of what influenced your thinking so that, if you come back in the future, you’ll know what other threads may have advanced in the meantime. I’ve thought of this as a way to contribute to open source that isn’t writing code or docs after the fact. Like, imagine you’re a Racket user and you wish there were a library to do X: maybe it’s a worthy contribution just to start a github repository and document the libraries that do something similar, and what you see as good and bad about those approaches. Maybe someone with the bandwidth to write the software will see your documentation and find that it gives them a head start.