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…
Old school developers - achieving a lot with little
21–30 of 41 posts
Re: Old school developers - achieving a lot with little
#22Re: Old school developers - achieving a lot with little
#23I 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…
Re: Old school developers - achieving a lot with little
#24For 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…
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
#25Agile 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.
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
#26Earlier 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
Re: Old school developers - achieving a lot with little
#27I 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.
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
#28Earlier 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.
Re: Old school developers - achieving a lot with little
#29Anyway, 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
#30I 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.
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.