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."
Re:Tool complexity leads to learning the tool (Score:5, Interesting)
He's doing them a disservice by fixing their problems. In the old days you bought a computer and there was no software for it, so you got a magazine with a program and you copied it in. You had no clue how the jumble of characters made it work, but it did ... until it didn't. If you dive in to fix the problem or to make it do something new on your own, you end up learning something about the system, about why things are the way they are.
GP needs to stop playing daddy and let the newbs grow by fixing the problems themselves.
Re:Tool complexity leads to learning the tool (Score:5, Interesting)
Your wording is in the wrong order. It is not that they have not bothered to learn what us happening 'behind' the IDE. They simply don't know how a computer, a network or distributed software works.
Either take them as programmers and let them use the IDE, or educate them about what they obviously did not learn in the university or simply don't hire them, but for god sake: stop complaining! If you hire people who don't understand how the code they produce is deployed to the production environment, then either make sure they don't need to know or ad I said above: stop complaining, change your recruiting habits!
Re:Tool complexity leads to learning the tool (Score:4, Interesting)
Nope, I don't work with Microsoft Technologies. ... ... /languages for coding 'real' software.
In 1997 a company I owned partly was so smart to use VisualSourceSafe as VCS (considering that it did not really work, I can not get why they did it).
Instead of having files versioned in files they used like SVN the database approach. And yes they had back ups.
When the VSS DB got corrupted, all work of two years of about five developers got lost. Well, mine was additionally in my private (back uped) RCS
Due to licensing issues it took them months to get the backups back into a working VSS
That was the last company I worked with MS 'tools'
If your environment demands to use particular tools because vi and text files are not enough, then something is seriously wrong. And I doubt that absolvents from universities that only can use MS tools and can only work in MS ecospheres save so much money in the long run that it is worth it.
Re:Tool complexity leads to learning the tool (Score:4, Interesting)
Re:Here is how to get in to coding: (Score:5, Interesting)
While this very true; it helps to also give them a place that requires speed to push them to type fast. I've always told people that asked "how do you type so fast?" that I learned to type really quickly by growing up in IRC chat rooms with lots of people and multiple conversations going on at once. You had to learn to type fast to keep up with what was going on.
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.
The only problem I've ever had with using "games" as a way to learn to code is that the final product may not match expectations. To put it another way. I love programming because it gives me a means to solve problems. Sometimes the problems are concrete as "I need a piece of software on my desktop to tell me when I'm getting a phone call on my phone." That problem is focused, the solution is focused too. If your phone rings and you get a notification on your computer, you know you solved the problem.
Games rarely offer up focused problems and solutions, especially for beginning programmers. A lot of game ideas are nothing more than "I want to make an RPG where I fight zombies." The solution would deceptively be to have a few characters in a bland world and some monsters labeled zombies, but game dev is never that simple and the problem space "grows." It goes from "rpg zombie game" to "rpg zombie hunting game where I must build a cure, save cities, and all while I'm working within this cool battle system." Games could be a great route to code but the path between problem definition and solution is huge compared to more simple stuff.
Maybe (Score:4, Interesting)
It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on.
Perhaps, but any such exploration and the resulting tools have to beat the baseline of a decent text editor, a decent version control system, a decent scripting language, and starting to write code within a minute of deciding the project is ready to begin.
For a long-running project with many developers and other contributors performing repetitive or error-prone tasks, maybe it will be worth investigating, selecting and adopting some external tools to automate some of that work, at some stage in the project when you know where the pain points are. But if your development team aren't newbies, they will be perfectly capable of building their code manually at first, they will surely already know their universal Big Three tools very well, and importantly, they will just code up any basic automation on the fly as the project grows and the needs become apparent.
IME, that turns out to be a surprisingly tough standard to beat. I've seen many, many projects get bogged down in their own infrastructure because they felt they should use some type of tool and forced themselves to do it, not because they necessarily needed that tool or found it useful in practice. Of course good tools can be useful, and of course sometimes it is better to bring in help from outside the project rather than being too NIH about everything, but it's important to stay focussed on the goal and not to forget that tools are only means to an end.
Welcome to the Next Level. (Score:5, Interesting)
I reached that point in the 90's.
Now I write all my code in a meta language that compiles down into COBOL, C, C++, C#, Erlang, FORTH, Fortran, Google's Go, Haskel, Java, Javascript, Perl, PHP, Python, Ruby, Rust, and more.
It takes about two weeks for me to learn a new language and write the "runtime" for my meta compiler. Then I can deploy all of my existing solutions on the new platform faster than the other guys can get "Hello DB Connection" out the door.
Fuck all the shitty languages and "new" platforms. Now that you've actually grown up and stopped being a fucking fanboy, go write your own meta compiler. I'll open source mine when I retire, it's what gives me the edge over all the noobs still wasting time reimplementing their wheels.