WingNews logo WingNews GitHub [2]
top | item 10713625

Tell HN: I spend so much time solving problems I feel like giving up

65 points| throwaway000020 | 10 years ago | reply

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.

58 comments

order
[+] rjknight|10 years ago|reply
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/

[+] jon_richards|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
> 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.

[+] kohanz|10 years ago|reply
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.

[+] johansch|10 years ago|reply
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.

[+] chipsy|10 years ago|reply
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|10 years ago|reply
> 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|10 years ago|reply
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|10 years ago|reply
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.
[+] throwavay_java|10 years ago|reply
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|10 years ago|reply
-----------------------------------------------------------------

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]

[+] alex-|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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!

[+] elros|10 years ago|reply
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.
[+] bonesinger|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
> 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|10 years ago|reply
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.

[+] mod|10 years ago|reply
Are you just learning?

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

[+] throwaway000020|10 years ago|reply
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.
[+] brad0|10 years ago|reply
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|10 years ago|reply
I'm trying to get an application built using a modern JavaScript approach.