
Tell HN: I spend so much time solving problems I feel like giving up - throwaway000020
I spend so much time trying to understand the development ecosystem and fighting my way through the build tools and development frameworks that I can barely get to write a single line of code. Every problem I solve leads to the next roadblock  and on and on and on. It&#x27;s depressing me and I&#x27;m feeling like maybe I don&#x27;t have what it takes to be a programmer.
======
rjknight
I'm guessing a bit, but it sounds like you're suffering from trying to find
the 'right' way to do something.

I've been in situations where I've spent weeks or even months re-writing
things because I read one more article about how some given approach is better
than the one I was considering. Ultimately it doesn't matter enough to make a
difference in the real world - your application will not be appreciably better
because you used gulp instead of grunt or React + Redux instead of Backbone.

That doesn't mean that there isn't a difference between those things, or that
some aren't better than others (I like React and would recommend it) but the
choice of tooling is not your main problem[1]. This is going to sound very
dull, but your best bet is to make some simple choices, stick with them for a
while, and see how far you get. Try to avoid questioning things for a while,
even if that feels really unnatural.

I think there's a kind of tooling FOMO that afflicts developers, where we get
worried that if only we were using a particular tool or technique then our
jobs would be, say, an order of magnitude easier, more successful etc. This is
hardly ever true, and if it _is_ true then you will be unlikely to be able to
identify the choice you need to make until you've spent a good while building
version 1 of your application anyway.

[1] [https://xkcd.com/309/](https://xkcd.com/309/)

~~~
jon_richards
I find that no matter how many charts I see detailing why one thing is better
than another, the decider is whether it has good tutorials written for it. If
it doesn't have a good tutorial then the rest of the documentation isn't going
to be much better and any actual problems you encounter won't have a stack
overflow solving them.

------
thom
I call this 'feeding the machine'. There's the thing you want to do, the
interesting, valuable, real-world problem you're trying to solve. But you're
using a library, that has a dependency, that doesn't build on your machine,
because of your version of the compiler, and the new version isn't in your
package repository, so you have to download and build it, but your version of
readline is wrong and so on and so on. You're feeding the machine constantly,
when you feel that it's supposed to be working for you.

It sucks, but it doesn't end. Every once in a while you're be in a nice place
where you're using familiar tools and libraries and doing familiar work, but
every new project and technology brings potential new demands to feed the
machine.

You can have a long, happy and prosperous career working with a single stack
that someone has made work on your OS of choice, but if you don't enjoy
feeding the machine, there is a ceiling on your flexibility and problem
solving ability.

~~~
cesarbs
> You can have a long, happy and prosperous career working with a single stack
> that someone has made work on your OS of choice, but if you don't enjoy
> feeding the machine, there is a ceiling on your flexibility and problem
> solving ability.

That's what gets to me the most. I'm fairly confident in my problem solving
abilities and coding skills. But I frequently lose all motivation to do good
work when 80% of what I do is "feed the machine". There are times when doing
it makes sense for the problem at hand, and then I feel motivated, but most of
the time feeding the machine is about dealing with shitty code, bad
documentation and unnecessary overengineering.

------
johansch
I have plenty of relevant platitudes :)

Go simple. Pick a language. Start writing code. Stay focused. Only solve the
problems that you need to solve, not any problems that you might maybe,
perhaps, come across. Don't go shopping for a toolkit until you have tried
building something yourself. Especially if you are young - remember that
writing code to solve problems that someone else has already solved is not a
lost cause; you are learning!

YAGNI:
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)

Remember, perfect is the enemy of good.

Today I think it's way too easy to get lost in the flood of of
platforms/toolkits/frameworks. When I got started 20 years ago it was a lot
simpler - crappier but simpler. :) You might or might not have what it takes
to be a good developer - but I seriously see the risk of potentially good
developers getting stuck before they learn how to navigate these new-fangled
floods of ... stuff. It's like a tax on brain cycles to keep up with it all.
If you have no discipline you will end up spending all of your cycles shopping
toolkits rather than solving problems and learning how to actually program.

------
chipsy
Stop-and-start development is completely normal when you introduce a lot of
project tooling and it's new and shiny.

For this reason, projects run by a solo developer tend to use less tooling and
process than team efforts; the friction introduced by each new step in the
workflow is a major penalty. The solo developer can just opt to ignore all the
cruft and use a cheap, lazy option, because there is no communication issue.

This also presents a bit of a dilemma if your goal is to learn a workflow in
order to get hired on a team using that workflow, because you will feel like
you are making nothing interesting or noteworthy. Your best option is to
temporarily change your mindset from "engineer building software" to "writer
building documentation".

The person documenting has to play detective and ask questions constantly. It
takes them four times as long to do anything because they have to write down
the steps and make it digestible. But each time they make progress and write
down those steps, they set down a little roadway for people to drive over in
the future. They also gain more credibility as an expert in the process.

~~~
joepvd
> temporarily change your mindset from "engineer building software" to "writer
> building documentation"

Excellent suggestion. But also here, focus on a tool and/or workflow is
warranted. Meandering the field is very productive; it has its time and place.
But it is not a panacea for a deep dive. Sustained focus remains necessary.

Writing documentation can be a rewarding, productive, and, yes, even noble
method for taking a deep dive.

------
hyuuu
I know exactly where you coming from, ESPECIALLY if you are in the javascript
ecosystem. There are a lot of gaps in the whole flow, from what you have
mentioned, build tools, frameworks, standards, architecture (flux? mvc?)

Personally, I would suggest, to go at it one at a time. The reason being,
these "things" (build tools, frameworks, etc) are there to solve specific
problems. If you don't have that problem, then you don't need to understand
it, yet.

Pick a project and start building, you might find that you need one specific
tool, which then you would use that specific tool or you might find yourself
having trouble with a certain design then you use a framework that fits your
model. This resonates well with @johansch comment. Over time, you will notice
a pattern in your knowledge where jumping from one framework to the other is
not that difficult because you are jumping from a higher board knowing the
frameworks you already used, this applies generally.

Be depressed but don't give up, the joy comes when suddenly it all just
clicks.

~~~
throwaway000020
Yes I am in the JavaScript ecosystem. I feel like I'm trying to escape from an
Amazonian jungle of errors and things that don't work, trying to find a path
that appears and disappears and sometimes is trodden by others and sometimes
grown over, always with thorns and strangle vines, dead ends, thousand foot
waterfall roadblocks. My food is running out and my feet hurt and by day the
sun burns and at night there are the eyes of the beasts watching and waiting
for me to fall.

~~~
krisajenkins
Writing JavaScript and feeling you're surrounded by errors is pretty normal.
It's a hastily-designed language. There's no getting away from the fact that
everything is going to feel a little bit fragile. Just accept it and don't
expect perfection.

~~~
muzmath
Hastily designed for version 0.0.1, this is simply not the case if you are
using modern EMCAScript

~~~
krisajenkins
Is equality still broken? Are maps still broken? Is it still a sporadically
whitespace-sensitive language?

~~~
qwertyuiop924
not AFAIK, but I am not an expert.

~~~
krisajenkins
Leading questions, I'm afraid. Yes, equality is still broken, maps are broken
(and in new & interesting ways in EMCAScript 6), and the language is
occasionally whitespace-sensitive.

JavaScript was hastily designed, has never recovered, and shows no sign of
ever fixing the fundamental problems. :-(

~~~
muzmath
Case sensitivity i'm assuming you mean the automatic semi-colon insertion due
to a line break after a return statement? I have a hard time seeing this as
being a reason to dislike an entire language.

Most languages have features to avoid, JavaScript is no different. Many
JavaScript developers use linters to avoid the poor `==` feature. I'm
unfamiliar with the argument of the `Map` datastructure implementation being
broken. Do you have a reference to that claim?

------
throwavay_java
You've already proven to yourself that the tooling that you are trying to use
is costing you time, not saving you time like you want.

Just don't use them for this project. Just build the project using what you
know now.

You can pick up that new tooling again at a later stage when you aren't so
pressured to deliver something.

99% of being a successful programmer is coming back tomorrow, and getting a
tiny bit more done, and learning a tiny bit more.

------
metasean
\-----------------------------------------------------------------

Relevant Quotes (Sometimes these help me push through)

\-----------------------------------------------------------------

> I have not failed. I've just found 10,000 ways that won't work. ~~ Thomas A.
> Edison

> A failure is not always a mistake, it may simply be the best one can do
> under the circumstances. The real mistake is to stop trying. ~~ B. F.
> Skinner

\----------------

Actual Advice

\----------------

Based on your question and comments, I'd actually suggest you reach out to
your friends in the community who know more about the tools that you think you
need. They might be able and willing to get you up and running with those
tools, so that you can move forward.

For example, I'm fairly junior, but comfortable with testing _once there 's a
framework in place_. I've been through this enough that I've reached the point
where I can get a basic Jasmine or Mocha framework up and running on my own,
but recently ran into a problem where I needed more than a basic set-up. I
mentioned it to a coworker and he said I needed Webpack. When I expressed
concern about spending time learning and setting up Webpack, instead of
working on my application code, he volunteered to get Webpack in place. As I
learn more about Webpack, the process of setting it up for my next app should
be less intimidating.

\------------------

Other Thoughts

\------------------

I love this meme -
[http://i.imgur.com/5mAUQj2.jpg](http://i.imgur.com/5mAUQj2.jpg) \- If you're
a programmer, you've certainly experienced both states. While I think I run
about a 1:1000 ratio, when I've spent a significant amount of time on the
right, I try to remember the sensation of being on the left and I know that
each mistake is one less mistake I can make and therefore moving me toward the
left.

And one last, very relevant quote...

> Do not fear mistakes. You will know failure. Continue to reach out. ~~
> Benjamin Franklin

[edited for formatting]

------
alex-
It might comfort you to hear: That almost everyone hits a steep learning curve
when moving to new technologies. That teams expect new members to take time
getting to know how everything works (they have been there). and that in time
you may actually find yourself craving that feeling of having so much to
learn.

Ultimately the times you are learning/improving the most are when you are
facing many new challenges.

If you are anything like me, you may find trying to find ways to enjoy this
time more helpful than trying to bypass or speedup this phase.

------
quicky123
My first large app I built the hard way. I started by copying code from
samples and modified them to my needs. I stuffed a bunch of api's together,
dojo, jquery, etc. I spent an inordinate amount of time testing the app and
modifying it to work on all browsers. Half of the time I didn't know what the
heck I was doing. I just obsessively kept hacking away until the app got
built.

Well, it got built and it's been successful for its built purpose. The code
isn't exactly pretty but it's fast and not buggy at all.

I spent the last year learning object oriented programming, software
architecture, ui toolkits. I'm just starting with react, typescript, node, aws
for my new app.

Because I built my first app 'the hard way' I now appreciate the value of
these toolkits and frameworks and think they're worth taking the time to
learn, but only if they simplify my process and not complicate it.

Keep working you'll get there and it's worth it!

------
qwertyuiop924
Pick a language. Write some code. I recommend one that requires minimal
building. Maybe python. If you need a build tool, use make. Use a text editor,
like nano, gedit, or notepad++. Not a complex one like vim or emacs. Keep it
simple. Now - And this is the important part - WRITE SOME CODE. It doesn't
have to be complicated, It could just implement cat or something. But the
important thing is to write it. Don't bother trying to find the "right way."
If you need libraries, go for the path of least resistance.

EDIT: This is important, so I want to say it as clearly as possible. FUCK. ES.
2015. ES5 is actually pretty good. Learn prototypical inheritance, or just
don't use OO. People have built real apps in ES5, you'll live. It might be
hard at times, and you might have trouble learning, but the important thing is
that you'll be writing code, not fixing your toolkit.

------
sergiotapia
Since I see that you're a Javascript developer, I'm going to suggest you
switch to something like Meteor.

It's COHESIVE. You have an idea and want to work on it? It'll just work, no
bullshit gluing together bits and pieces from other libraries. It's comes with
realtime, javascript everywhere, documentation is on point.

I can guarantee it's going to restore your faith because you will spend most
of your time writing your features and ideas, instead of glue work. Nobody
likes glue work.

\---

Where do I start? Right here: [https://www.udemy.com/learn-meteorjs-by-
building-10-real-wor...](https://www.udemy.com/learn-meteorjs-by-
building-10-real-world-projects/) \- you build ten real world apps, not some
shitty task list garbage. I promise you won't regret it, it's -fun-. Like that
first time you used Rails way back when? That kind of fun!

------
elros
I've read you saying you want to tryout modern JavaScript applications. Look
for a boilerplate repo with the tools you like and fork it. It's tedious to
set up the tooling part and if you want to focus on proper coding, that's the
easiest way to get started.

~~~
tlarkworthy
\+ 1, specifically either fork a github base project e.g.[1], use yeoman[2]
and there are also some gems in maven archetypes[3].

[1] [https://github.com/tylermcginnis/re-
base](https://github.com/tylermcginnis/re-base)

[2] [http://yeoman.io/generators/](http://yeoman.io/generators/)

[3] [https://maven-repository.com/archetypes](https://maven-
repository.com/archetypes)

------
bonesinger
I was tasked with building a WPF project with no prior experience. I jumped on
pluralsight for a lecture on wpf and mvvm, then started building the app. I
realized I could use a framework for mvvm but I've learned a lot by doing
everything from scratch. At one point I realized I needed some plugins for
help (INotifyPropertyChanged, I'm looking at you) and started using them,
which has made my life considerably easier. Build the project, use what tools
are necessary. Don't let tools dictate your project. I've been down that hole
a lot with JS. Gulp, Webpack, Grunt, Node, Express, Babel, ClojureScript,
TypeScript, and it goes on and on and on.

------
wonnage
Having worked with webpack and babel at large-social-network for the past
year, they're great tools and make a whole range of things possible. But as
soon as anything breaks or behaves unexpectedly you are in for a hell of a
time even just figuring out at what layer or step of the pipeline the breakage
occurred.

So it's not just you. I would never set any of this up from scratch for a
personal project. And I don't expect you'd need to, ever - established
companies will have an existing pipeline (with its own problems you'd never
learn externally), and new ones can just use one of the various boilerplate
project templates.

------
3pt14159
Stop rushing yourself. It takes time to build up skills. Keep learning. I've
been at this for 20 years, and even I have gaps and frustrating days. You'll
get better. Just keep improving every day.

------
dperalta
> You can't connect the dots looking forward you can only connect them looking
> backwards. So you have to trust that the dots will somehow connect in your
> future.

Don't give up and keep learning!

------
erlich
The JS/React ecosystem is moving rapidly right now. I got caught in the middle
of a storm when I updated my toolchain from Backbone/Sprockets to
React/Redux/Webpack. There was Flux, then a bunch of Flux implementations,
then Redux took the crown - a library which didn't exist a few months back.
But as Redux has taken the crown, Relay has emerged along with it's own
alternatives such as Falcor. Then there is Angular 2 on the horizon. Back in
the day it was Knockout vs. Backbone which made things a lot simpler.

There is a proliferation of [boilerplate
projects]([https://github.com/xgrommx/awesome-
redux#boilerplate](https://github.com/xgrommx/awesome-redux#boilerplate)) out
there at the moment but they are quite heavy and all do things a little
differently.

I think what is lacking and will emerge eventually is some glue to fill the
gaps that everyone is identifying. I think it will be a few small core
libraries with some conventions about project structure, toolchain, and
modularity.

------
mod
Are you just learning?

Use less-shiny stuff. Ditch the frameworks etc. Do the simplest thing.

~~~
throwaway000020
I'm trying to build a real application and building real applications seems to
need to sew together a whole bunch of real bits n pieces.

~~~
davidbanham
I build real applications out of real bits and pieces in a modern javascript
stack. I do it for a living, have done for a while, and manage a team of
people in a company that does it.

Don't get hung up on tooling. Things like babel, webpack, ORMs, graphQL, gulp,
react, redux, etc etc etc. They're all useful things that have a place in the
world. If you try to grok all of them all at once you'll send yourself insane.
You don't _need_ any of them. Not a single one.

Just write some code to solve the problem in front of you. Then write some
more to solve the next one. Then come back and refactor. Then write some more
code and solve some more problems. Keep going like that. You'll end up with a
useful thing at the end of it.

The thing you end up with may not be as modular/scalable/etc as something a
seasoned professional could build with All The Tools. That's fine. It'll work.

Importantly, though, some slightly muddy, homebaked code will meet your needs
a hell of a lot better than a collection of half-understood learning about the
most fashionable frameworks of 2015 and no actual code.

~~~
throwaway000020
The paradox is that IMO the simplest way forward is to use the most modern
tools. The modern tools and languages are generally there to make things
easier. The trouble is that you need to learn those tools and languages before
you can get to do it the easy way.

For example, I really can't afford to program with any JavaScript language
except ES2015 - I just don't have time to try to understand all the weird
idiosyncrasies and underpowered crap that is older versions of JavaScript - I
need to work with "JavaScript that makes sense" i.e. ES2015. But to do that I
need to be able to wrap my head around - and fight all the myriad problems
with - getting my ES2015 to compile using the webpack babel toolchain.

It's a strange thing about programming that to understand the easiest way to
do it you need to have a higher order understanding of the entire programming
system that you are working with.

~~~
_cudgel
_The paradox is that IMO the simplest way forward is..._

I feel like this statement is the crux of the issue. Have you considered that
your opinion is simply wrong?

~~~
johansch
OP: It hurts so much when I run into walls.

Everyone else: Stop running into walls then.

OP: But they are so shiny. I think running into them is the best way forward
for me. Please keep me a trick that allows me to run into them without pain.

Everyone else: Eh..

------
brad0
I'm guessing you're feeling depressed because you don't have a strong idea of
why you're doing all this.

I'd say that what needs to change is your mentality.

There's a lot of things you can do to change how you're thinking. It all comes
down to understanding the essence of why you're feeling this particular way.

What are you trying to achieve?

~~~
throwaway000020
I'm trying to get an application built using a modern JavaScript approach.

~~~
ausernamehere
I know where your coming from, a few months back I had a run in with getting a
yeoman generator working on my system. I had all sorts of problems with that.

You probably already aware but just in case your not one possible option for
you is to try a vm like virtual box using one of bitmani's pre configured
systems

It's not a silver bullet but it may help

PS

If you do give virtual box a go don't use shared folders, at least not until
you have got your build tools installed and running.

------
guscost
What's currently in your JavaScript stack? I'm probably going to suggest
getting rid of most of it if possible so that you can focus on your code.
Here's a dirty secret: you probably don't need a JS build system or anything
from ES2015+ if you don't feel like learning it yet[0]. If you're using React,
you probably don't need to integrate any of the latest tech like Redux and
tcomb-form and all those other super cool innovations. You can even get away
with using Node modules in the old-fashioned "link to a script file" way[1].
Sure, someone can claim that each of those tools serves a purpose and can
prevent a whole class of headaches that might happen. What they won't say is
that trying to wrangle them all together right away is causing you a bigger
headache than any of the others!

I'm working on an application that has about 15K lines of hand-prepared
React/Flux JavaScript (well, TypeScript) and it is planned to scale up by
maybe an order of magnitude eventually. It's built with ES5 and plain old
revealing modules. I'm managing dependencies by hand. I'm not using Node or
CommonJS modules at all. Heck, I'm not even using JSX yet because my version
of Visual Studio doesn't have TSX (TypeScript+JSX) built in. Does this mean
some headaches and extra labor? Sure! Do I feel like an imposter when reading
about all this awesome fancy new stuff? Sometimes!

But the headaches are surprisingly minor and barely figure in most of the
time. If/when these headaches get bigger (I suspect this will start in earnest
when more front-end developers join the project), then I'll take another look
at integrating a module loader, or a form generator, or an automagic React
router, or a super-cool atomic state system like Redux. In case you're
wondering the application works amazingly well and most of the time
implementing even far-out crazy features has been easy and fun.

Finally, don't get too worried about making the "wrong" choices, and don't
bail out for something newer when you hit your first roadblock. Most of the
options you have available these days work great! The things we expect them to
do are totally incredible, that's the only reason people are still proposing
alternatives all the time.

[0]If you don't need to support older browsers, ES2015 is pretty easy to
include. Otherwise if you need to use examples based on an ES2015+ version,
just paste the code into the Babel REPL:
[https://babeljs.io/repl/](https://babeljs.io/repl/)

[1]You can get any bundled npm module here:
[https://wzrd.in/](https://wzrd.in/)

------
ksenzee
All that "modern" tooling is simply there to solve problems people have
encountered. Give yourself a chance to experience the problems first, before
you go adopting everyone else's solution to those problems. Just write some
plain old code that works.

------
sonabinu
You are going to get better as you learn more. You will still need to figure
out how to set up things but you will have more tools in your tool kit to help
you. Keep an open mind and remember you are learning as you struggle through
things.

------
drumdance
AKA yak shaving -
[http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_t...](http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html)

------
Ellahn
I get the impression you are learning, if you're not, I suggest you think
again, because actually you are. :D

Programming is much about learning and it never gets easy when you need to
pick something new. I suggest you find a mentor if you don't like
experimenting alone, somebody who can give you some guidance.

After you learn something, it gets easier, and very rewarding.

On the subject of "not having what it takes", I disagree. Find a friend who
draws, sings, plays an instrument or whatever, and ask them to tell you how
much effort they had to put to learn their craft.

"Computers" are probably a lot easier, at least in comparison, since you have
to use them anyways.

------
facepalm
There was a link to a programming advent calendar on HN a while ago:
[http://adventofcode.com](http://adventofcode.com)

Solve some of those puzzles once in a while, no tooling necessary. Or if they
are too easy, go to project Euler.

I also feel the same frustration of JS tooling. It's just not a lot of fun to
go through so many steps before you can actually start coding. I hope it gets
better once the basic setup works.

------
hnuser123
No one gets the perfect start, and there are gonna be painful change as you
progress and realize past mistakes. That's part of the learning process.
Regardless of the changes you're still improving and gaining experience, and
that's never a bad thing. Try to look more on the positive side of things.
Take small steps and satisfaction once u get it, then move forward.

------
such_a_casual
Use pencils and paper. Learn one tool and learn it well.

------
gt565k
Just use Rails with Heroku for deployments. You can deploy a small instance
for free on Heroku.

It'll save you the headache if configuring and setting up everything, and with
a feature complete framework like Rails, you'll hit the ground running and be
cranking out features in no time.

------
quicky123
One more thing, when I first read about something like Grunt or Backbone, I
didn't really get it. After several months of reading blog posts, articles,
books and hacker news I started to get it.

