Live data from Hacker News

Old school developers - achieving a lot with little

dodgycoder.net

11–20 of 41 posts

Re: Old school developers - achieving a lot with little

#11
post #8
post #7

Earlier quoted context omitted.

Patches sent over email (yeah, please try doing a pull request to see what happens) Interesting, since git is used by kernel devs this can't just be a convenience thing. Why are they so adamant about putting the patch in the email?

Because you can directly review and discuss the changes inline without the need to leave your mua. There is also no need to setup a public git repository and check all your changes in your repository before pulling. git format-patch, git send-email as well as git am work also really well and simplify the patch creation/integration. This is basically the send a pull request from github but without the need to depend o…

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 perl. The rest was on a whiteboard.

Re: Old school developers - achieving a lot with little

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

Re: Old school developers - achieving a lot with little

#14
post #11
post #8

Earlier quoted context omitted.

Because you can directly review and discuss the changes inline without the need to leave your mua. There is also no need to setup a public git repository and check all your changes in your repository before pulling. git format-patch, git send-email as well as git am work also really well and simplify the patch creation/integration. This is basically the send a pull request from github but without the need to depend o…

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

Re: Old school developers - achieving a lot with little

#15

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 productive with VIM (because I am unfamiliar with it) and I frequently fight back a strong urge to go back to eclipse (for debugging, refactoring and object relation checking/mapping). I guess this is the kind of thing that keeps making everyone go back to their favourite IDE/editor.

Re: Old school developers - achieving a lot with little

#16

On Ken Thompson: Regarding his programming style ... hardly ever uses unit tests, starts his projects by designing the data structures and then works bottom up, with throwaway test stubs. Sounds to me like he does use unit tests, but then throws them away after he's content that the code is working. I think this is what most people did for non-trivial code before unit testing became a culture.

Yup, I remember when I was learning Python, before I ever wrote any real tests, all my modules would be littered with:

  if arg[1] == 'test1':
    print func1(a)

  elif arg[1] == 'test2':
    print func1(b)

  elif arg[1] == 'test3':
    print func2(a)

  ...
Eventually I found it was way easier to stick this in a _test.py file :)

Re: Old school developers - achieving a lot with little

#17
post #5

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…

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 think there's a plus and a minus to the class navigation features of IDEs. Undoubtedly they make it faster to find your way through a thread of code, helping you to avoid breaking concentration and flow. However, I also observe that many of my colleagues who exclusively use an IDE never actually learn the structure of the codebase. Starting in on a bug or a task from scratch, they don't have the instinctive knowledge of what file & method to go to straight away to start working on the problem which I feel like I've gained via time spent navigating the codebase more manually.

Re: Old school developers - achieving a lot with little

#18
post #5

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…

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.

Re: Old school developers - achieving a lot with little

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

Re: Old school developers - achieving a lot with little

#20
When designing software he prefers to rigorously document as much as possible up front before starting to write code...

This was really good for me to read. Coding is much more fun than planning, so I get pulled into the trap of staring at my screen while thinking things through, trying something, then approaching a better solution. I am trying to make myself create a clear plan on paper before turning my computer on. Only when I have a clear approach outlined on paper do I get to turn my computer on.

It's less "fun" sometimes, but it's much more satisfying.

Post reply on HN