Chad Fowler

It sounds like you may not be "dumb", but maybe just a beginner who is struggling to get to the next level. Here are a few questions I'd ask first before you decide programming is not for you.

1. Do you work with other experienced and passionate programmers who can mentor you?(http://chadfowler.com/2011/02/24/be-careful-of-who-you-work-with)

2. Do you know how to learn? A lot of people assume it just comes down to reading the material, I found this book explains the process quite well and it is put in the context of a software developer looking to attain mastery http://www.pragprog.com/titles/ahptl/pragmatic-thinking-and-learning

3. Have you "cultivated your gurus" so to speak? Putting up a post on HN is a great start, but continually involving yourself in discussions in the greater community will help you to tap into a source of experienced mentors even if you don't work with them. Find groups for topics you are interested in and then involve yourself, ask questions, learn, then contribute to the discussion yourself.

4. Have you considered getting involved in some open source projects? These are a great place to learn from others as well.

In the end learning isn't generally as simple as just reading a few books for most people. I would consider starting with a few books on how to get your career development and your learning process on the right track and then go from there. Even if you do decide you're not cut out for programming, what you learn from those books…

throw away account...

I work at a small hedge fund in London, started on £28k (actually might have been less, I literally can't remember now), after 4 years I am up to £40k, with around £5k bonus each year.

I have basically been doing CRUD of various flavours the whole time under a bullying atmosphere, utterly soul-destroying and it's got me stuck in the Stockholm syndrome scenario, my skills ground down to the point where I literally can't get another job to get out of it. Am working very hard to counter it, but it's a big job, probably another year of work to stand a chance of getting a decent software job (I'm not going to try for another internal finance job, if that sucks as much it'll be pretty impossible to bear).

So yeah, I don't recommend it, though it might just me having bad luck here.

I think very few internal jobs, finance included, are even vaguely bearable for hackers - I heard the idea that finance likes to hire overqualified people for monotonous/trivial jobs to make sure they're done right, so you have to be really careful.

[1]:http://www.chadfowler.com/2010/12/30/dead-end-jobs-are-you-suffering-from-stockholm-syndrome

Just because it's a satire doesn't mean the title in incorrect. I would argue that Ruby is, in fact, the future for the same reason that Python is the future.

As for monkey patching, yes, it's ill-advised in general just as global scope and gotos are ill-advised for similar reasons. However, monkey patching is a powerful feature if used responsibly as Chad Fowler has noted ("The Virtues of Monkey Patching"):

http://chadfowler.com/index.cgi/Computing/Programming/Ruby/TheVirtuesOfMonkeyPatching.rdoc,v

Now admittedly, not every programmer is as competent or responsible as Chad Fowler or the programming world would be a very different place but the point is there's a right way and a wrong way to do it.

Werner Schuster's article on InfoQ ("Ruby's Open Classes - Or: How Not To Patch Like A Monkey") has more good advice on how to do it the right way:

http://www.infoq.com/articles/ruby-open-classes-monkeypatching

Allan was saying "the end is in sight" 6 months ago.

http://blog.macromates.com/2009/working-on-it/

This really reminds me of a series of blog posts by Chad Fowler, warning against the "big rewrite."

http://chadfowler.com/2006/12/27/the-big-rewrite

Now he says the next version will be out "maybe in 6 more months if everything goes right." In other words: "I have absolutely no idea when or if I'm ever going to finish it."

Which, of course, is fine. It's his project and he has every right to develop/mismanage it as he sees fit. But I got tired of waiting for basic things like split-window to be implemented and went back to vim a while ago. If 2.0 ever comes out I'll definitely check it out but for now I'm happily using vim.

> Docker on the other hand is not just a third-party library in your project. Docker is a container

What's the difference, exactly? In either case, a failure in the code composing the third-party component can, at worst, cause an instance of your application to crash and corrupt state, preventing instances on that machine from coming back up.

But as long as you've got immutable deployments[1] set up, when all else fails, you can just destroy the server (hosting the containers) hosting your app instances, and deploy it afresh, which should be automated to the point that it only takes a few minutes.

[1] http://chadfowler.com/blog/2013/06/23/immutable-deployments/

Treating the old application as the spec for the new one is usually not a good idea. Define the problem(s) the new application is trying to solve instead of trying to copy the behavior of the old application. This is important for both developers and users. (http://www.chadfowler.com/2006/12/28/software-as-spec)

I like tackling the tougher parts first as assumptions usually conflict with the real world and the design will change once you start building and testing.