Live data from Hacker News

Old school developers - achieving a lot with little

dodgycoder.net

21–30 of 41 posts

Re: Old school developers - achieving a lot with little

#21

I think you are most effective with the tools you have been using the longest which are probably the ones you started using first. I started with things like QuickBasic and PHP, so debugging by print has always felt natural to me. This is a problem with things like Java that were clearly not designed around this paradigm where you should really be using a debugger or setting up log4J or something.

Totally agree. Over time, everyone develops a particular style of working with their favourite editor/tools and it becomes very difficult to move away after a point. I worked with Java on Eclipse for 8 years, and I am taking a self-imposed break from it and working with Java on VIM for the past 2 months. There are benefits to both approaches (editor vs. IDE) but the main thing I notice is that I am far less productiv…

As someone who writes Java using VIM for my job, http://eclim.org/ has proven invaluable. I suggest taking a look at it if you haven't already.

Re: Old school developers - achieving a lot with little

#22
Although rxon are from the emacs side, Armstrong has a pet-project for an IDE, that keeps a kind of browsing history related to the code. He noticed, that many lookups happen before a few lines are written. And after they are written, the "why?" is lost, i.e. how the author actually got to the given lines needed. Hence the lookup history for the web searches.

Re: Old school developers - achieving a lot with little

#23

I don't like this title, because emacs is not "with little". Nor is the command-line interface. These lightweight development tools took a lot of work to get right. Creating a modern keyboard-only (mouse breaks flow) development environment that works is no small accomplishment. My tooling preference is evolving a bit. I used to hate IDEs, because I associated them with the (thank God it failed) attempt to commoditiz…

Debuggers are also great on platforms without the modern conveniences such as memory protection, i.e. microcontrollers. Segfaults are annoying, but at least they are clear- mess up on a machine with no memory protection, and you start executing random memory.

Re: Old school developers - achieving a lot with little

#24
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 the code is going to do some good. On the other hand, I find it useless to have processes that distort reality (e.g. pretty UML documents about what the code might do, if only someone had written the code that way).

Re: Old school developers - achieving a lot with little

#25
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 out of the window for time to market. Sure your first few iterations will survive this, but as your product grows, so will coupling logarithmically. This eventually cripples you.

Re: Old school developers - achieving a lot with little

#26
post #11

Earlier quoted context omitted.

I've worked in a couple of companies that did this. We had the following flow and it worked great: Task assigned to developer via email, developer takes current release tar from ftp and untars, does work, creates patch, forwards patch to colleague to review, forwards to release manager who integrates all incoming patches, drops into a new tar, releases to ftp. Some of this was automated with a few hundred lines of pe…

Interesting They could skip the ftp part, because git saves bandwidth Still, this is a good way to do the work

They use scp now rather than ftp. They don't use git because it's too complicated for contractors to handle.

Re: Old school developers - achieving a lot with little

#27
post #13

I agree with the overall thrust, though the printf debugging technique is much more suitable for a relatively deterministic program like a compiler or command line tool than for many interesting programs like OSes and network services.

Actually, it's the other way around. Logging [which is pretty much what printf debugging is] is much more sustainable for long-running nondeterministic programs. It's far easier to look at a log and say "After 3 hours, this program started giving bad responses for these specific inputs".

Debuggers are great when you know where to attach and what to look at, but finding that information out is far easier to do from a log.

Re: Old school developers - achieving a lot with little

#28
post #18
post #5

Earlier quoted context omitted.

If you're on-boarding into an existing Java project and want to be productive in your first week, I think using an IDE is the only answer. 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. Intellij can make Java almost enjoyable to use. Your comments on agile and standups are spot on. Where I work now we d…

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

Re: Old school developers - achieving a lot with little

#29
There was no such thing as TDD programming when I learned to code. Same with these old guys. There also were no interactive debuggers (or at least not like the new ones).

Anyway, I used to use the interactive debuggers in Visual Basic and Visual Studio, but for the web its easier to just be in an ssh terminal and so I just use logs.

If you want people to use TDD, then they should start learning it close to when they start programming, and I think that will make it much easier and more natural for them to do.

I have done some TDD, but not very much because it always feels like extra work. What I am used to doing these days is sort of small feature test programs when I need to and its convenient or just running the application and looking at logs. I think if I had learned to program with TDD it would be a lot easier.

Re: Old school developers - achieving a lot with little

#30
post #19

I don't like this title, because emacs is not "with little". Nor is the command-line interface. These lightweight development tools took a lot of work to get right. Creating a modern keyboard-only (mouse breaks flow) development environment that works is no small accomplishment. My tooling preference is evolving a bit. I used to hate IDEs, because I associated them with the (thank God it failed) attempt to commoditiz…

> 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, to drag them across arbitrarily designated finish line.

Meanwhile, startups, small companies, and the few large companies who take engineering seriously are bidding up the rest of the talented programmers. With cash, with freedom, with the ability to actually make something they aren't depressed by.

Post reply on HN