Comment by highCs | Hacker News Reader

Comment by highCs | Hacker News Reader

At my own surprise, I now often blame the developer (the team and me) and not the business, in such a situation. There is 2 reasons:

1. You can develop 10x faster than what you think. Learn functional programming and more importantly, learn to code bottom-up. Even if you do object-oriented code, that will do.

2. As a developer, you must take the initiative and drive aggressively the projects. They must listen to you, not you listen to them. Literally put your job at stake, often. If you do so and if you got results (see point 1), you gonna gain respect very quickly, then take the initiative and become unstoppable. But, before thinking about that, you need point 1.

You are the code pro, if things goes wrong about code, you are the one to blame. The spiral is you thinking you are the victim. You must understand than software must serve the business, not the opposite. Finally, nobody told software development was easy.

EDIT: I should say something here: I'm talking from experience. This is what I do, and I can testify it works. Also, it's not supposed to solve the problem, it's supposed to prevent the problem to happen.

It's nice to believe in superpowers, but this is a matter of scaling rather than one of a high constant value - even if you are 10x 'faster' (which does not mean better in many cases), when the issues piling up are scaling superlinearly compared to your organization's development capacity, you will still have a problem.

Sure, my point is you get there because developer didnt do 1 and 2. Once there, I agree with you, solutions are different.

Please expand on what you mean by "code bottom-up". I am somewhat skeptical about your advise to be honest, although I certainly agree that taking responsibility is important in oranisatitons in general.

http://paulgraham.com/progbot.html

Bottom-up is the art of coding a project from scratch. If you got the mastery of it, it means you can start and finish a project very efficiently. The idea is that you make the codebase evolve, you scult it. You code like the painter paint. By doing so, you can get a prototype very quickly and then refine it into a final product. Whatever is the time you're given, you always have a working code with every features - like a painting has everything in it even when it's not finished (and it never is). The only thing that can be missing are relative details.

I know it might sound like every other software development methods. The thing is that most developers are actually bad at it - that's point 1.

Learn functional programming <- I remember hearing the same argument for object oriented programming 20 years ago. The good old golden hammer :)

Learn the tool or technology that fits well your problem space whatever it might be : golang for highly concurrent server side, functional for something that maps easily to math stuff, event based programming for request/response, etc.

Reply on news.ycombinator.com