Slashdot Mirror
Getting Back To Coding
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."
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.
Play Command HQ online
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!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
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.
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.