Ask HN: 45-minute “unblock me on my personal project” consultants?

I’m a consultant and I have a client on an arrangement like this, where I don’t really do much actual work but just give advice. I structured it as an up front retainer that I bill hourly against as I’m needed.

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.

npm, gems, rvm, protractor, node-debugger, etc

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.

  1.3e12

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.

This is a very good point that I knew, but didn't express clearly in my OP and is exactly the sort of thing that I should be good at communicating. I definitely would want to

> 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.

My comments about testing were specifically triggered by Protractor which seemed to be a technology that was creating friction. More generally, testing is like any other engineering decision: subject to a cost benefit analysis not an end in and of itself. In the end, all that matters is the business logic...to the user.

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.

> In the end, all that matters is the business logic...to the user.

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.

This describes 60% the personal interactions I see and participate in, just hanging around a hackerspace. Actual collaborations happen, but a large portion is just unblocking each other -- the little tap on the shoulder, "hey, I think there's a better way to do that" -- and then going back to working on one's own stuff.

I wonder if there might be a social solution to this, simply by changing where you do your work.

> 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.

Buy a yellow rubber duck. Describe to it where you've gotten stuck.

This is a great idea.

I have a plushie goat and this works for some things. In particular, when you're stuck on something which you mostly understand but you're missing something or when you are comfortable working at that layer of abstraction.

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 guess you are looking for something like Codementor: https://www.codementor.io/

Huh, that looks like exactly the place I'm looking for. Fantastic.

codementor.io is what I use when I want to be walked through a solution to a problem I'm having.

Fantastic. This is what I was looking for. :D

You can use Upwork for that as well.

I hear you. I hate package managers. Package managers are introduced by misguided people not in order to solve a development problem, but a language popularity problem.

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".

It sounds like you’re frustrated with some complexity surrounding package managers.

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).

I would recommend a different approach. Look at what you are trying to do, like the jobs to be done framework. If you want to build side projects, build side projects. Use simple tools that are easy to learn, have many examples, and have a helpful community.

I use twitter hashtags to unblock me.

Those who made you that feeback are wrong. Package managers suck (especially npm). Do what's comfortable for you not the others.

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.