Ask HN: 45-minute “unblock me on my personal project” consultants?
I’m trying to get back into doing side projects for my own learning. However, I have a problem and I’d like to know if I can trade money for a solution.
Back when I was in uni or a new grad, I frequently repeatedly had a problems with package managers, setting up test frameworks, figuring out how to use a debugger to get to a point in a test, package managers, other development environment issues, and especially package managers. My response back then was to spend hours yak shaving and going down rabbit holes. As a student, this led to a lot of wasted time. When I got to the workplace, this habit led to me getting some pretty strongly-worded feedback that I needed to get better at asking for help when I ran into these sorts of problems. After a few years, I’ve mostly gotten over the “I’m not a real engineer if I only have a surface-level understanding of npm” feeling. Asking well-framed questions leads to a coworker popping up and unblocking me pretty quickly and the team as a whole moving more efficiently.
But what do I do for personal projects?
Is there anyone who has a really solid understanding of npm, gems, rvm, protractor, node-debugger, etc. and offers the service where I can book time on their calendar a week from now, send them a clear description of my problem, and videochat with them for 5 minutes to 45 minutes and then pay for 45 minutes of their time? What would rates generally be?
Folks with experience doing consulting or services, how would you structure such a transaction? Would it be best to have someone on retainer? Or would they just have themselves up on calendly as described here: https://calendly.com/pages/customer-stories/freelancers-and-consultants ?
21 comments
[ 4.0 ms ] story [ 59.0 ms ] threadMaybe the service is to create nice docker images for side projects. E.g. a rails app with login and all the usual stuff with best practices and you go in and tailor it to your side project
I wouldn’t do it without a retainer because the extra friction of an hour here and there is not really worth it unless I can get a nontrivial amount of cash up front, which helps balance my cash flow while working on other longer term projects.
Customers don't care about git and such things. I don't use git because I find it useless for the projects I'm working on.
But for development environment issues where the key is some piece of knowledge like "run rbenv rehash" that you just don't have, it doesn't work.
I wonder if there might be a social solution to this, simply by changing where you do your work.
I'm totally interested in finding a place in London where I can show up with my laptop on a Sunday.
I used to hang out at one of these spaces in uni and found that I went down rabbit holes a bunch still. I suspect that my question-asking skills have improved to the degree that I can mostly avoid that now.
Random advice from the internet. The root problem space is NP. Ignoring that NPM -> node and javascript, gems -> Ruby && gems -> g >= 2, rvm -> Rubies >= 2, protractor => Angular, and minimizing etc. to c == 2, there are 7! combinations. Or more visually, a graph with 5040 edges.
More realistically, there are > 15! edges. Prune the graph with 99.99% efficiency and you've still got a billion things to get wrong, misunderstand, ignore or wire together. Consider starting with the simplest thing that might work. Side projects probably don't need end to end testing. Probably not Node and Ruby. At least in the beginning.Circling back, to the 7! there are only a handful of humans with those qualifications, even fewer of them that are consultants, and ~0 that are likely to read this thread. It is likely that you are among the leading experts on the 15! technology.
All this complexity gets dealt with by teams. One person knows RVM, Gems (2!). One person knows NVM and Node-Debugger (2!). One person knows Protractor and etc. (3!) and the problem space starts to look more like P than NP.
Good luck.
> Side projects probably don't need end to end testing.
yea, with Selenium is a frustration that I generally avoid. I recently discovered https://www.cypress.io/ which I'm just getting started with.
On the general point of keeping it simple: I definitely agree that you shouldn't add tools you don't need. But automated testing is necessary self-care for software development.
Something I sometimes see with people's side projects is a box full of tools thrown in the repository upfront and then little or no progress followed by abandonment. My take is that all that tooling for continuous integration and automated builds and so forth gets added because doing so is easier than solving the problem. Or more importantly building some prototypes and proofs of concepts and designs that fail. I suspect from observation and experience that all that tooling makes prototyping and spikes harder and more tedious due to configuration and complexity. Or to put it another way, setting up Selenium and Jenkins and whatnot right from the start looks like progress but isn't because there is nothing to test and no application to continuously deploy. Trying to avoid writing the app twice (or three times) often results in writing it zero times.
If you're trying to build a side business and a side project to support that business, you are 100% correct. If you're trying to build a side project for your own learning, then the user is the developer, the primary interface is the codebase, and all that matters the developer experience.
But you should start by understanding what developer experience you are trying to achieve and design from that. Trying to get yourself set up with a good red-green TDD loop? Adding Jenkins from the start is probably a mistake because it won't help you with your local dev environment. However, if you're starting out learning node then getting webpack configured will probably help you. But here too there is a trap: you want to avoid just collecting a list of tools you don't know and trying to assemble them into a dev environment all at once without guidence. I once spent a week trying to do that with gulp and it was nuts. This is one area where talking with someone who is experienced with the language's ecosystem will help you. At best, that person can point you to a recommended setup. The very least, that person can point out that some tool is 2 years old and doesn't play well with the others because it is out of date.
Newbie programmers don't know enough to pull individual libraries that they need and put them into their project in a sensible way that they then understand. This causes a newbie language to lag behind popularity against other newbie languages that have package management, or else have needed features built-in. Solution: cave in and make a package manager here too.
However, the package management eventually causes problems such as depicted by https://xkcd.com/1987/
Package management, other than at the OS distro level, is an antipattern. Language packages should be installed by the OS distribution's package manager. E.g. on Debian or Ubuntu it should be "apt-get install whatever". Not "apt-get install idiotic-manager" followed by "idio install whatever".
They can be complicated but they’re not invented to torture people. They solve real world problems.
Some are better than others. The best thing I can say about Rust’s Cargo is I have no clue how it works because Its never given me cause to find out (ok I roughly know).