Getting Back To Coding 240
New submitter rrconan writes I always feel like I'm getting old because of the constant need to learn a new tools to do the same job. At the end of projects, I get the impression that nothing changes — there are no real benefits to the new tools, and the only result is a lot of time wasted learning them instead of doing the work. We discussed this last week with Andrew Binstock's "Just Let Me Code" article, and now he's written a follow-up about reducing tool complexity and focusing on writing code. He says, "Tool vendors have several misperceptions that stand in the way. The first is a long-standing issue, which is 'featuritis': the tendency to create the perception of greater value in upgrades by adding rarely needed features. ... The second misperception is that many tool vendors view the user experience they offer as already pretty darn good. Compared with tools we had 10 years ago or more, UIs have indeed improved significantly. But they have not improved as fast as complexity has increased. And in that gap lies the problem.' Now I understand that what I thought of as "getting old" was really "getting smart."
Join a Free Software Project (Score:5, Insightful)
Write code.
Tool complexity leads to learning the tool (Score:5, Insightful)
The problem mirrors that of big word processors (Score:5, Insightful)
...Everyone says "I only need 10% of what this word processor will do." Everyone else will agree with that statement. The problem? The 10% I need is not the 10% YOU need.
I find the article strangely short-sighted. Sure, we have to avoid overengineering solutions that are not going to be needed in the near future. But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.
A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."
Further, our tools are complex because our needs are complex, even at the SMB level. I've been a developer for 30 years now, writing everything from experimental personal-use stuff, to local utilities, to enterprise software that is used by some of the largest manufacturers on the planet. Even small users expect unanticipated cases to work. Big customers expect that, not only do unanticipated cases work, but that migrations to new versions will be tailored to THEIR needs and will happen without notable incident. As but one small example that means that internal testing of a new release not only has to work as a brand new install, but it must also work as an upgrade, and it must work as an upgrade against the specific data and specific customizations (real software is customizable), even when you don't know what those are. If you expect success in that environment, you're going to need a LOT of tools: source code management (to identify what changed when you introduce a regression), an automated testing framework, a way to test builds and build functionality, a framework for testing upgrades against real customer data (that they let you use for this purpose), and then tools and processes that let you track code reviews, approvals, and the like. That's a lot of tools, and a lot of staff to follow it all around.
My organization has some excellent tools, and developers assigned solely to maintain them for the rest of the development staff. It means, though, that any new developer coming in is going to have to learn a lot more than a programming language.
I'm bitching about SQL Server Management Studio (Score:5, Insightful)
No criticism of the OP here, but this got me thinking about one of my mortal enemies. The UI within SQL Server Management Studio. For the last decade of upgrades, I've really wondered how that development team leaves the office everyday thinking they are doing a good day's work. There are so many blatantly apparent rough edges to the UI for SSMS, I can't believe they think it's as good as they can make it.
In order to avoid tldr, I'll just give a single example. Look at the tabbing for each database connection window. The tabs are labelled "servername.database" but are limited to a small number of characters regardless of how many tabs are open. Here's an example where there are only two open tabs:
http://img.informer.com/screen... [informer.com]
The first reason the labelling is fundamentally broken is that the database name is chopped off in an unnecessary abbreviation. The tab could stretch out to display the whole thing! It's not scrunched in with a bunch of other tabs. There's plenty of room there.
The second reason this is broken is that the database name is the thing you actually need to see more than the server name. In the majority of use case scenarios, the user is connected to multiple databases on the same server. When switching tabs, you need to be able to locate the one for the database you're looking for within your current connections. Sure, there's that pulldown menu on the left, but that's a much further mouse drag than the tabs are from your focal point.
So, if you're ever looking for an example of a developer interface that doesn't get a proper update, look no further than SQL Server Management Studio. It's hardly changed in over a decade of releases.
Here is how to get in to coding: (Score:5, Insightful)
Build something. Find a problem and solve it. It doesn't matter what the problem is or how you solve it.
Write a tic tac toe engine, or a photo slideshow generator, or a fart joke generator, or whatever you want to do. But you just have to do it.
Re:Here is how to get in to coding: (Score:5, Insightful)
Precisely.
I work in independent (private) schools. We have a few "star" pupils who want to be coders. They generally don't become them, not because they're not skilled, or couldn't do it, but because they've never sat down and done it outside of lessons that they waltz through. Following a course by-rote isn't learning.
I also get asked an awful lot (by the younger years) how I type so fast and how they can "learn" to type that fast. Type. For years. Bang, you've learned. This is no shortcut, there is little technique, no amount of learning the home keys will help you type fast. You just have to type, lots, all the time.
Same for coding. You can learn some theory. But to learn to code, you have to code. And with kids it's really easy - pick a game, program it. They know every kind of game, they will rarely fully complete anything approaching a full game before they get bored, disillusioned or just plain hit the limit of their skill level. The way past that point is determination and learning what to do. And that comes by just demanding that you code and discipline yourself.
The true "stars" are the ones that persevere through those problems, solve them and come out the other end with ANYTHING approaching a complete program that isn't entirely trivial. Next time they have a coding problem, they know they just have to work at it to get past it.
"Featuritis" in the whole computing ecosystem (Score:5, Insightful)
New languages. New frameworks. New IDEs. New magic procedures...
Some of it is good, surely. Who programs without classes these days? But every time I see someone come up with a magic new net language, framework, etc., I sort of cringe. I mean, do we really need another one? Do we need all the ones we have (I'm lookin' at you, Ruby...).
The elephant in the room here that Microsoft, et. al. seems happy to ignore is that it takes time to learn AND recode this stuff. Time is money. If you're a teen or a student, you have time to mess with the next Ruby, or Dart, or GO, or BrainFuck or...
As a kid, you have no money invested, and plenty of time. There's no risk.
Fast forward 25 years. You still code for a living. You have a house, a wife, kid(s), car(s). You and your spouse are paying for all of this. Suddenly, genius boy at Microsoft invents Powershell! and convinces a few PHBs to roll it out. Suddenly, all your clients want Powershell! Quite frankly, you haven't got the time or interest in learning Powershell!. You wanted .net features added to VBScript and/or Jscript. You wanted backwards compatibility with existing VBscript and Jscript code. You wanted something that added value, not something that subtracted value by forcing you to go back to the drawing board and recode perfectly functional tools to satisfy a corporate IT security requirement from the corporate PHB that says, "Use Powershell!" for which you may, or not be paid, depending on how well your contract was written.
Disclaimer: I like Powershell, but it was the wrong decision.
The problem, quite simply, is this: Change!=Improvement. Change!=Better. Sometimes you get lucky. At other times, not so much.
Re:Tool complexity leads to learning the tool (Score:4, Insightful)
The idea that the IDE becomes _necessary_ to access the code is spot on. We do code security reviews as part of our work, and, for example, most Java projects cannot be reviewed anymore without the Eclipse set-up that was used to produce them. That is pure insanity!
If I was in charge, I'd march around the whole office and generously apply boot to fundaments.
I got burned REALLY, REALLY bad in my Visual Studio days because it was difficult-to-impossible to get a makefile out of it, depending on which release you were working with, and once the IDE had been replaced with a newer version of the IDE, some projects couldn't make 1-line emergency fixes without either massive project rework or re-installing the old version of the IDE.
Moving to Java wasn't much better, because although the IDE in question wasn't Eclipse, projects couldn't be built without the IDE plus the same directory setup as the original developer.
Because of the expense and lost time at critical moments, I have a very strict policy that and project under my control must be buildable using a well-supported non-gui build system that can be set up and used in under 10 minutes with no external user system dependencies or other tweaking. In other words, Ant, Maven, or an equivalent product.
Re:Welcome to the Next Level. (Score:5, Insightful)
That sounds like a great idea. Since you're coding for the least common denominator, you obviously get none of the benefits of the target language, while still suffering from all of its issues, plus whatever additional issues are introduced by your under-spec'd and idiosyncratic "meta language" and "meta compiler".
To top it off, no one else will ever be able to maintain or build on what you write, so you're stuck with that job forever, unable to move on to something better—or at least until TPTB wake up and realize that it's far more trouble than it's worth and throw it out in favor of something which is properly idiomatic and standardized and which doesn't make them wholly dependent on you and your "meta compiler".
No thanks.
Re:"Featuritis" in the whole computing ecosystem (Score:5, Insightful)
Rapidly introducing new tools and deprecating old ones unnecessarily is part of Microsoft's business strategy.