Any time a claim starts with the clause "It's a new era...", you should automatically be wary. Modern times have brought a slew of incredible advan...
For further actions, you may consider blocking this person and/or reporting abuse
I started programming professionally in the 1980's, primarily C and MASM, using ASCII text editors. I had to write my own tools and extensions to editors to do things that are integrated into the IDE today. I don't get the attraction to doing things retro that seems to be a trend now. I see no advantage to ditching the efficiency of modern IDE's to use command lines and such on a real paid project.
It might be fun, I guess, to see how things were done in the "old days", kind of like driving a Model T car on a Sunday afternoon country drive. But that Model T's appeal would wear thin quickly if you drove it as a daily commute with no AC, no Bluetooth, no radio and so forth.
Well, I never said it was "fun" or "trendy," nor am I advocating for ditching IDEs and doing everything "old school" as a rule, so I suspect you may have missed something in the article. In fact, I explicitly said...
I'm not referring to doing this manually as an end or habitual practice, but rather as a means for honing certain skills...skills which, when paired with the modern convenience of an IDE, allow one to write better code faster.
I write some of my code in
edand I ship that code online. Ha!Smacks @tux0r with his own source.
Heh. A promise is a promise! :P
Happy that I write soft-ware then... being smacked with hard source could hurt!
Even though modern editors have made software development a bit easier and manageable, it's not the only way to go about doing it.
I know a few very experienced software developers who still use ed, which is a line text editor (not even a full screen text editor) and has no support for virtually anything that modern software developers rely on (e.g. auto-completion, syntax highlighting). Instead, they rely on the entire ecosystem of tooling (e.g. command-line tools) to accomplish the task.
Honestly, there might be an exception if someone has honed their craft to that point. Still, the tools (in some fashion, at least) should be involved somehow, at least as a safety net. If you're going to write your program in the command line, it had better run through a linter, proper tests, and the like.
Autocomplete and syntax highlighting do have their place: they prevent some of those pesky minor errors we all miss. It's not impossible to work without them, but they are useful.
However, for the record, that statement was primarily for the younger coders who don't have 30 years experience in making and fixing mistakes while coding without the safety net.
Certainly.
I was not suggesting that engineers should develop without safety nets.
On the contrary, when I said...
I meant exactly what you have said; they run their code through stringent pipelines locally and remotely to guarantee quality of software.
I guess the point I was trying to make is that for modern software development, I would have placed the emphasis on practices that guarantee quality of software, rather than on tools.
In other words, you can use whatever tool you feel comfortable with as long as you adopt the practices to guarantee a high quality of code.
Edit: Analogy:
Say, I use a ball-peen hammer to drive a nail and you use a you use a regular hammer to drive a nail. If you make a mistake, you're tool has built-in facilities to correct the mistake and remove the nail. If I make a mistake, I have to reach for a different tool to correct the mistake. But as long as we both can deliver same quality product, does it matter that I used a ball-peen hammer?
I think I agree. I just didn't want to leave that much room for the group of inexperienced coders that uses text editors out of sheer laziness for learning how to properly use anything else. ;)
It's kinda like building a dining room table with only hand tools, to be honest. For most people, it's going to take a lot more time than necessary, unless you're this guy...
So, until you're that guy, probably shouldn't be trying to ship critical code with only those tools.
My first language was C at university in 2005 but the first language I had professional experience with was FoxPro for DOS in 2008. By then I was already introduced to OO with Java and C# also at university.
The IDE didn't have any kind of intellisense or highlighting. I had to fully understand the language instead of waiting for the IDE to teach me only when I made a mistake.
This made my code better and my coding reflexes more natural. I believe that those 4 years working with a terribly outdated language made me a better programmer in Java, C# or Kotlin (which are my main daily languages today).
That being said, it is great when a well thought out IDE like IntelliJ tells you stuff that you didn't realise but are obvious like testing strings like "text".equals(variable) to avoid nullpointers in Java or when it alerts you to whole 30 lines blocks of code that are completely duplicate and you can refactor, etc.
IDEs are great and should always be used in a professional setting, but doing challenges on notepad are a good thing to do from time to time.
Thanks for sharing your experience!
I guess the point is: make good use of IDEs, but don't depend on them.
Yes, exactly.
Probably because we're in different sectors. Application development, everyone and their mother relies on IDEs. It's just the expected default behavior. By contrast, web development hasn't really had any decent IDEs until the last few years (save for WYSIWYG editors, which don't count in this regard).
Agreed! I try to editor hop at least sort of regularly, and while I have settled into an IntelliJ groove of all things of late -- my preference when using any IDE is to disable as many of the tools it carries as I can.
I usually:
I'm glad we started that conversation, because this is a very nice read :).
Those skills you mention (e.g. print statement debugging) are indeed valuable skills, but I consider them quite separare skills, that may or may not be useful depending on the context (like knowing the ins and outs of a specific language). As such you're only a better developer for having them when the context requires them.
As to being able to change code quickly without an IDE, the only context I can think of that warrants that kind of haste, is when something is wrong in production, and there: with or without an IDE, it's dangerous and should generally not be done. Most cases I've come across where this was needed were in fact because someone had made a (non-critical) change for which they had bypassed the proper CI and/or acceptance flow.
Yeah, it's a rare case, although it sometimes can't be avoided. Still, I don't advocate bypassing the CI!
IDEs might alert you to bad habits that may slow down your code even if functional. They could alert you of duplicate code that could be refactored into a single method.
Thing is that an IDE might show you a second opinion on your code, which is always a good thing. It makes you think over that masterpiece of a code you just chiseled and find a little extra nipple for you to remove
This article reminded me of my old me:
Back in the days when I was pretty young and very obsessed with programming, I once write a full "game"'s code on paper - the "F1 on math paper" game. Pascal, 640x480 graphics mode :) (I was spending my summer vacation at my grandparents and had no access to a PC there.)
When I got back home and typed the code in, it was working flawlessly -- at least this is the way I remember it :). It felt good. It still feels good.
Shoot, I actually added some functionality into the print wrapper I wrote for my company's utility library, which allows certain messages to be flagged as "debug only". That way, when the "verbosity" is set to high, they'll print, but when its normal or below, the debug messages won't even be parsed!
But, yeah, leaving those in is definitely a valid problem. Still, a decent code review process should catch them.
Editors are tools. IDEs are tools. Version control systems are tools. Even programming languages themselves are tools.
As long as the right tools are used, and the job gets done... it's all good.
I primarily use Vim, Xcode, Visual Studio, Perforce, and C++14 these days (with some Objective-C, Objective-C++, and C on the edges). They get the job done.
I love sublime for this. It's not and IDE (although it can be), it's more a powerful text editor. I recently switched to vscode and often I find myself pulling up sublime on a few files.
If anyone knows of a sublime plugin to auto import ts classes like vscode does, that's really the only reson I havn't gone back.
Good article! I'll admit I haven't gone as far as you have, but learning a level below what I ultimately end up using does help a lot.
I forced myself to use only Notepad++ for my introductory HTML/CSS class a while ago. I didn't look for any kind of autocomoplete in that editor, and it forced me to learn the correct syntax inside and out.
Also, when I was learning git, I learned in the CLI. Granted, I followed the CodeSchool videos for learning git, but I stuck to CLI for a while after that. Now I'm both a CLI and GitKraken user, but having learned git in CLI has helped me understand much better how to work with a git GUI.
Thanks for writing this article. I completely agree with everything you've said. Everyone should at some point work on some complex projects using a basic text editor, followed by an editor in a shell.
My analogy is to computing math in your head vs. using calculators. I lost those complex mental computational skills once I started to rely on calculators (and wrote programs for the TI to simplify that further, lol!).
I recall back in the 90's, my friends called me the human compiler because I would spot errors in everyone else's code without needing to compile it. That was a very useful skill as I could save so much time when build processes took several minutes to hours. IDE's ruined my reputation for good! 😆
Hi Jason, you make very fine arguments, just a few points:
not your fault but I think we should stop comparing carpentry or bridge building to software development, in general. The cost of a poorly done wall is not the same of a typo, for mainstream software development at least and if it is, that's why a lot of people are working to develop safer tools (see the whole idea behind Rust)
some types of software development (iOS programming for example) are quite obnoxious to do without IDEs, or systems where code is auto-generated...
I hope desk checking does not pick up, for the sake of the environment. You can still export code in PDF and reading it on the computer or phone if you really have to.
Anyhow, I think your whole argument is about developing a deeper knowledge of how computers work and how software development works, especially now that Moore's Law is dead
Ps. prints are fine but we should remind people to remove them. I've seen so many codebases with debugging prints left in for production. At least use logging levels 😛
For what it's worth, I live in the northwest U.S. Forestry is critical to our ecosystem here, and it's an ongoing treadmill to keep the forests from becoming overdense. So, around here, paper is quite good for the environment, because it's a good use of a resource we need to heavily thin anyway! (An overthick forest is a burning forest.)
That aside, you can do desk checking without printing, as you've described, but I think it needs to come back as a practice in some medium at least.
Also, if you make a mistake building a wall, the wall falls over. If you make a typo in a piece of software, the results range from a minor inconvenience to a lost satellite, from a screen flicker to a catastrophic, fatal plane crash. We should NOT be downplaying the seriousness of bugs.
Now, that said, there are some differences between engineering fields (sciences) and programming (more of an art than a science). Where the comparison is apt is still in the tools. ;)
I have used all these techniques while using an IDE. Not sure they are mutually exclusive. Did they help me write better code? For me I can't really say yes to that. What helped me is learning why readable code is so important and learning TDD. I would rather teach someone TDD first before teaching them using a debugger. It becomes a big time waste when you write a bunch of code then try to figure out what went wrong in ther debugger or even trying to step through the code in your head. I think knowing this has value but again not sure it helps anyone write better code.
This is a good chance to mention my article about IDEs which don't spoil you with shiny colors and intelligent anti-programming features again. :-)