Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Old school developers - achieving a lot with little

dodgycoder.net

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Old school developers - achieving a lot with little

#31

Post by wpietri »

raverbashing wrote: post #3

Well Unit tests are great in js/python/ruby because of the nature of the language In C/C++ for example it's much more involved. In java it's bearable because of Eclipse/Netbeans facilitating lots of things. But take for example the Linux kernel development: - There are two widely used "IDEs": VIM and Emacs, pick one - Patches sent over email (yeah, please try doing a pull request to see what happens) - No unit tests…

I like unit tests and CI even with excellent developers who I trust utterly. We just have the computer automatically check everything we might check manually. Or that we worry that we might forget about.

Re: Old school developers - achieving a lot with little

#32

Post by wpietri »

TimPC wrote: post #12

Agile is about working with large numbers of people on code that's constantly changing. The examples you use seem like code that gets written once or as part of an individual project. Unit tests gain most when they get run multiple times by different people over the life of a project.

Is it? I've only been doing it since 2000, so maybe I've got it wrong. But I thought it was about working more efficiently and adaptably by tuning our processes to embrace change rather than trying to fend it off.

Re: Old school developers - achieving a lot with little

#33

Post by wpietri »

b0 wrote: post #25
TimPC wrote: post #12

Agile is about working with large numbers of people on code that's constantly changing. The examples you use seem like code that gets written once or as part of an individual project. Unit tests gain most when they get run multiple times by different people over the life of a project.

I'm not sure I agree. I've watched large numbers of people crash and burn running 'agile' processes. Agile doesn't work at all with large numbers of people on code that is constantly changing. Regardless of how you package it, the only way to achieve coherency and scalability of product development is through extensive planning, solid architecture and loose coupling of components. Agile throws those three concepts ou…

I certainly agree that a lot of "agile" projects are clusterfucks, especially large ones. Of course, that's true of all software projects. And a lot of what people sell as "agile" is bullshit. So I'm not sure how much that proves.

I also agree that well-run agile approaches throw big up-front design out. But I think they can happily achieve solid architecture and loose coupling.

There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release. The main differences are that you need some supporting practices to make refactoring economical, and that you have much more information available to you after release than you do before-hand.

Re: Old school developers - achieving a lot with little

#34

Post by gizmo686 »

zxcdw wrote: post #9

For the most part, the most important thing is to get things done. Sitting down and writing code. Nothing else. When you add all the fancy modern "methodologies" and tools, practices and whatnot then most, if not all of them just steer you away from the actual task of "sitting down and writing code". Of course, this is domain specific in a sense that agile methodologies aren't that suited for a sole developer, than t…

Thats just the attitude that put me out of running shape for two months, I ran to much, to fast, to soon, and get a stress fracture, and kept running on it until I got a worse stress fracture. The most difficult part of running is knowing how much to do in order to get better, without doing so much that you get worse. The same logic works in programmning, investing time so you know what you want to write not only lets you write it faster, but results in cleaner code that is easier to use, maintain, and likely has fewer bugs.

Re: Old school developers - achieving a lot with little

#35

Post by gizmo686 »

makecheck wrote: post #24
zxcdw wrote: post #9

For the most part, the most important thing is to get things done. Sitting down and writing code. Nothing else. When you add all the fancy modern "methodologies" and tools, practices and whatnot then most, if not all of them just steer you away from the actual task of "sitting down and writing code". Of course, this is domain specific in a sense that agile methodologies aren't that suited for a sole developer, than t…

Writing code is a straightforward task. What takes days or weeks is scanning and deciphering someone else's buggy digital hairball (and those programmers also thought they were "getting things done" when they "finished" their unmaintainable messes). I'm not a huge fan of IDEs or complex processes, but many tools do help. A debugger, static analyzer, and heck even 'grep', go a long way; really, anything that looks at…

grep is the single most useful tool in my aresenal. With it, I can can take the source code of a library I have never looked up before, and immidietly find the function I want to know about, if I'm feeling nice, I might even submit a documentation update.

Re: Old school developers - achieving a lot with little

#36

Post by pjmlp »

wpietri wrote: post #30
pjmlp wrote: post #19

Earlier quoted context omitted.

> I associated them with the (thank God it failed) attempt to commoditize programmer talent Why do you say it failed? I do consulting for Fortune 500 companies, and I am pretty convinced it was successful, based on the majority of guys we get assigned to our projects.

You've seen a project you'd call a success? I'm kidding, sort of. I haven't seen the inside of a Fortune 500 company in years; I'm in startup-land now. But from what reports I hear, I imagine it's the same. Lots of "commodity" programmers driving the costs up an order of magnitude beyond what more talented programmers consider reasonable for the functionality. Then they pay a few brilliant people, often consultants,…

Yes, I would say that you described the situation pretty well.

The problem is that even medium sized companies are following suite. My problem while looking for jobs is that it is becoming the same everywhere.

Re: Old school developers - achieving a lot with little

#37

Post by pjmlp »

orangecat wrote: post #28
pjmlp wrote: post #18

Earlier quoted context omitted.

> I would argue if you're using Java, using an IDE is the only way to stay sane. Context aware class navigation is pretty much a requirement on any sizable project. This applies to any language, not just Java.

It's not so much the language as the practices that have developed around it, such as the "everything happens somewhere else" principle of strong OOP. Which has some advantages, but means that you'll be flipping through lots of classes to trace most code paths.

If you have a large codebase written by several generations of developers you'll get this. Even in languages without OO support.

Re: Old school developers - achieving a lot with little

#38

Post by jdietrich »

A computer scientist called Alick Glennie worked alongside Alan Turing on the Manchester Mark 1 computer.

Glennie developed Autocode, a "simplified coding system" - what many regard as the first real programming language. The story goes that when Glennie developed the first compiler for Autocode, Turing was furious that precious computer time was being wasted on such a task. Turing's mind was supposedly so brilliant that to him, the task of implementing a program in machine code was mere admin, something requiring no more skill than making up a punchcard. It simply did not occur to him that other people might consider computer programming to be complex enough to be a vocation in itself.

For once-in-a-generation geniuses, no safety net is necessary. The rest of us need to be protected from our own incompetence.

Re: Old school developers - achieving a lot with little

#39

Post by zxcdw »

gizmo686 wrote: post #34
zxcdw wrote: post #9

For the most part, the most important thing is to get things done. Sitting down and writing code. Nothing else. When you add all the fancy modern "methodologies" and tools, practices and whatnot then most, if not all of them just steer you away from the actual task of "sitting down and writing code". Of course, this is domain specific in a sense that agile methodologies aren't that suited for a sole developer, than t…

Thats just the attitude that put me out of running shape for two months, I ran to much, to fast, to soon, and get a stress fracture, and kept running on it until I got a worse stress fracture. The most difficult part of running is knowing how much to do in order to get better, without doing so much that you get worse. The same logic works in programmning, investing time so you know what you want to write not only let…

Yes, I've experienced the same when I began running. This is equivalent to a junior developer spouting out code without thinking. It's not only the act of actually physically typing the code, but the thought process involved - juniors are not able to think before they type. I'd argue that people like in the article have written more code, have spent more thinking, debugging and maintaining code than a huge, huge majority of "modern day hackers" ever will, in 21st century. They focused at the task at hand, and became extraordinary good at it.

Re: Old school developers - achieving a lot with little

#40

Post by b0 »

wpietri wrote: post #33
b0 wrote: post #25

Earlier quoted context omitted.

I'm not sure I agree. I've watched large numbers of people crash and burn running 'agile' processes. Agile doesn't work at all with large numbers of people on code that is constantly changing. Regardless of how you package it, the only way to achieve coherency and scalability of product development is through extensive planning, solid architecture and loose coupling of components. Agile throws those three concepts ou…

I certainly agree that a lot of "agile" projects are clusterfucks, especially large ones. Of course, that's true of all software projects. And a lot of what people sell as "agile" is bullshit. So I'm not sure how much that proves. I also agree that well-run agile approaches throw big up-front design out. But I think they can happily achieve solid architecture and loose coupling. There's nothing you can achieve with u…

Well actually you're wrong on the following point:

There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release

If your application is relatively standalone then yes, but if you have heavy APIs and integration (which value adding applications usually do), you're up shit creek.

Post reply on HN