Hacker News new | past | comments | ask | show | jobs | submit login
Tell HN: I spend so much time solving problems I feel like giving up
65 points by throwaway000020 on Dec 10, 2015 | hide | past | web | favorite | 58 comments
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's depressing me and I'm feeling like maybe I don't have what it takes to be a programmer.



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/


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.


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.


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


I really like this analogy! The only thing I'll add is that I don't think you necessarily have to enjoy "feeding the machine", but as you said, you need to realize that it doesn't go away and that a lot of our value as software developers comes from our ability to continue to make forward progress when it happens (and sometimes even inventing a new way around it). I certainly don't always enjoy it while it's happening, but I do feel a sense of accomplishment when it's finished.

This phenomenon is one also of the biggest reasons people who set out to "learn to code" end up giving up.



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

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.


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.


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


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.


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.


Speaking as someone with a lot (20+ years) of dev experience, I highly recommend that you switch to a more mature language ecosystem. Other than the fact that it's in every browser, javascript is a horrible place to learn how to code.

Javascript development is a total mess. Even very experienced people spend a ton of time trying to navigate that ever-shifting terrain. It's also a very primitive, clumsy language, missing the most basic tools that a developer might want (e.g. first-class includes and packages, for starters). To top it off, in my experience, the average JavaScript developer is quite inexperienced. The good examples of javascript code are outnumbered 100:1 by bad examples.

If you're doing web dev, Ruby and Python are good places to start. Pick a language where there are a core set of experienced leaders who have been working for years, and there's a small set of "right" ways to do things.


Sometimes it helps to go back to the basics. Just write the simplest possible app, without frameworks or anything. You'll figure out what the pain points are for you, and suddenly frameworks and tools will make way more sense.


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.


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


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


not AFAIK, but I am not an expert.


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


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?


Equality isn't really as broken as people seem to think. And if it bothers you that much, use ===. Yes, it can be annoying, but it works.

What do you mean about maps, and whitespace sensitivity? I've never heard anything about that.


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.


-----------------------------------------------------------------

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


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.


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!


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.


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


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.


+ 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

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

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


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.


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.


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.


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


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


Are you just learning?

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


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.


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.


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.


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?


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


I'm with everyone else here that says you need to forget about the trendy junk and get the job done.

Think brutally effective rather than elegant or modern. The simplest most old fashioned method that will work is often good enough.

> The trouble is that you need to learn those tools and languages before you can get to do it the easy way.

this is never some weird tradeoff, this is simply people selling you bullshit and you buying in.


Just get babel running without the webpack and modules gorp.

I thought it was all a mess too and wasted a few hours.

babel ./*js -s -w -d ../../target/

Move on to solving real problems with code.

I agree with your sentiment that you should try at least get es2015 going though.

Good luck.


Bleeding edge tools have the drawback of people not fully knowing their flaws and drawbacks.


By real application do you mean complicated?

I'll second what others have said; you really don't have to use every framework. I really don't see anything wrong with building it with the simplest tools possible, and then if you feel like you need better tooling finding something which fixes your specific problem.

Honestly most things are there to fix some use case, but in my humble opinion you're better off running into said use case before using some framework because you'll understand the problem it addresses and abstractions always leak.


I would start with "real applications" that do very simple things.

Load in an instagram feed. Query some api and show results. Have one model and make a basic CRUD app around it (todo list?).

Do that several times (seriously).

Eventually, when you understand all the basic pieces, start tying two of those things together in one app. You'll learn new things.

As you go on farther, you'll learn the whole stack piecemeal, in digestible amounts.


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?


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


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.


I'm a mobile developer by profession but I just started working on a web side project. The first web stuff I've touched in almost a decade! I feel your pain.

There's so much that can go wrong in modern web dev it seems.

The tech stack I'm using is: Nodejs backbone mongoDB

Is this the kind of thing you mean by modern JS approach?


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/

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


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.


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.



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.


There was a link to a programming advent calendar on HN a while ago: 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.


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.


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


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: