things you wish you learned earlier

[psycopathicteen]

I recently learned how to include multiple text files in an asm file, and I really wish I knew how to do this earlier, because I'm yet again reinventing the wheel.

Anybody have been in similar situations?

[tokumaru]

I wish I knew everything I know about programming now back when I was a creative teenager and had nothing to do during most of the day.

[koitsu]

I wish I had learned earlier how utterly shitty present-day programming languages are (mostly circa 1996 onward) and how they truly offer very little in the ways of improving what was already available. Oh wait, that would have meant being able to predict the future... oh well. ;-)

I wish when I was in my teens I had known what life would had in store for me in 2000.

I wish I had been able to predict that I'd essentially become a "dying breed" of technican/engineer/programmer (and I'm not the only one who feels this way; an old roommate of mine feels identical in this regard).

Is that getting too deep, or were we mainly referring to programming techniques/familiarity with platforms/things like that? :-)

[Bregalad]

I wish I knew everything I know about programming now back when I was a creative teenager and had nothing to do during most of the day.

Oh my, this is so true ! I feel so much the same way !

Not only programming but computer science in general (programming is the easy part of it).

[tepples]

I wish I learned how to drive so that I could have taken a job in a city that actually has jobs.

[tomaitheous]

I wish that I had picked one more right number on that lotto ticket, to win $1million instead of $2k... I'd be making all kinds of homebrew games right now.

[psycopathicteen]

I wish I had learned earlier how utterly shitty present-day programming languages are (mostly circa 1996 onward) and how they truly offer very little in the ways of improving what was already available. Oh wait, that would have meant being able to predict the future... oh well.

I wish when I was in my teens I had known what life would had in store for me in 2000.

I wish I had been able to predict that I'd essentially become a "dying breed" of technican/engineer/programmer (and I'm not the only one who feels this way; an old roommate of mine feels identical in this regard).

Is that getting too deep, or were we mainly referring to programming techniques/familiarity with platforms/things like that?

I started learning c++ and I still have no clue why so many people think this is easier than asm. C++ is so abstracted that it becomes confusing to figure out what the codes actually do.

[rainwarrior]

C++ is so abstracted that it becomes confusing to figure out what the codes actually do.

The point of the abstraction is not to have to figure that out.

[Bregalad]

I started learning c++ and I still have no clue why so many people think this is easier than asm. C++ is so abstracted that it becomes confusing to figure out what the codes actually do.

C++ actually is the most complex programming language ever invented. They included every feature that ever made it into other languages, including many redundant and normally mutually exclusive ones. This makes it both it's strenghts and it's weaknesses.

ASM is just simply machine code with nice mnemonics so it's actually understandable for human. Extremely easy to learn, extremely complicated to master

[drk421]

I wish I'd not been so scared of programming that I ended up doing SysAdmin for 10 years.

[tepples]

C++ is so abstracted that it becomes confusing to figure out what the codes actually do.

The point of the abstraction is not to have to figure that out.

That can prove desirable when performance is not an issue, such as early development when you're concentrating on getting the result to become correct. But by the time you ship your program, it should return the correct result in a reasonable time. Not figuring out what codes actually do causes people to write uniformly slow code. See C++ FQA 10.9 and 32.10.

[Bregalad]

Caution : This FQA is terribly biased and has been written by C++ haters.

Not that part of they say isn't true, but they exaggerate C++ shorts comings to their maximum, a lot of what they say is nonsense, and doesn't even mention it's advantages, which is the fact, they included so many features in C++ that it's extremely likely you'll be able to do what you want and do it the way you want. However it's extremely unlikely you'll understand someone else's code

[koitsu]

C++ is so abstracted that it becomes confusing to figure out what the codes actually do.

The point of the abstraction is not to have to figure that out.

Apparently you've never had the "pleasure" of using the following things in combination: Ruby 1.8 (language), Sinatra (framework), Padrino (framework), Rack (framework), ActiveRecord (framework or something, still not sure), and MongoMapper (I can't even explain to you what this is, but it interacts with a Mongo database, just in some utterly weird way). Oh and I'll throw in Plucky, which is the database driver for MongoDB (which should make you wonder what the hell MongoMapper actually is in itself, right?).

I deal with these at work on a daily basis (it's now part of my job), and have been doing so for 2 months now. Just last week I asked a co-worker what this one particular method (function) did because I couldn't figure out how on earth to use it. His first response was "no problem, let's work on it together". He starts to try to find docs -- can't, the docs give no information about its calling arguments aside from "implicit names". So he's forced to go look at the actual source code to the framework on github. This takes a while and in the process he "gets lost" by it; there's no comments in any of this code by the way. Eventually he re-focuses and manages to determine that it actually is an abstracted/exported method from another framework. Goes to those docs -- no information. Again, github source. Source explains nothing, like before. This forces him to put me on hold for a while, and after 2-3 hours, finally comes back and explains that it actually comes from Rack, and though there's sparse documentation, this is how it works. I ask him "how would I have been able to figure that out on my own?" and his answer was "you wouldn't have been able to. I've been doing this for several years and even I had never gone and done this before".

MongoMapper is another great one. How do you feel about "abstracted" method/function names that are dynamic and not declared anywhere in the code? Say, for example, someobject.find_by_name()? You go looking through the entire source repo to find the definition of find_by_name but there is none. It's a mystery... until your co-worker tells you about dynamic queries. This confuses the living fuck out of me, so he proceeds to step me through it. Still makes no sense, although my brain at this point is saying "oh god, please do not let this be some idiocy where the function name itself can just be 'variable' and there is some horrible function that matches strings as function names, like a wrapper function". After an hour or so, I am shown this and this. My heart sank -- my gut feeling was correct.

The above two cases are real-world situations which have happened to me. I dealt with them last week. I will also point out that at my job, in the past 9 days I have written a total of 3 lines of code. NINE DAYS, THREE LINES. While I am not a programmer by profession, do I even need to state the obvious of how this makes me feel both worthless and like I'm incapable of accomplishing something?

This is the reality of programming today -- nothing is linear, nothing makes sense, nothing is documented (correctly), and -- the best part of all -- chances are the people writing this garbage have no idea how a computer (read: processor) actually works/behaves. It's like constant tunnel vision, where "thinking outside the box" means "creating more vague ambiguity and crazy madness". All I see are brogrammers en masse, creating utter crap in bulk and releasing it into the world for others to use. Nobody knows what's going on under the hood though.

There comes a point, and usually quickly where the abstracted design approach loses its intention (the cut-off point, if you ask me, is 3 layers. Any more and you lose sanity). The intention of the abstraction, meaning the intended design, was to allow a person to simply use a class/object without having to know anything about its innards -- except that in most cases, you really do have to know about its innards to understand either 1) what to pass the method/function, 2) how the method/function actually behaves if passed something that manipulates data, or 3) why existing code is using this particular method/function in the manner it is ("I keep seeing the person do X, then call this method, then Y right after, almost like the method has a bug in it...").

What I have learned about myself is that I am an extremely "procedure-oriented" or "linear" programmer, and this stems from the fact that I grew up programming in assembly, BASIC, Pascal, and classic ANSI C. I put "procedure-oriented" in quotes, and did not choose to use the phrase "procedural programming", because the definition of that does not really match what I'm trying to say. I don't like there being "magic bullshit" going on within a program -- it makes it very hard to debug and virtually impossible for someone new to understand what is happening. I'd been given kudos repeatedly at my last job about the (perl) programs I wrote because guys who had never looked at them before were able to understand exactly how something works from start to finish simply because I apply KISS principle "without being a dick" (smarmy perl programmers often want to show off / flex proverbial muscles by writing horribly cryptic one-liners -- I do not do this), and because I comment well (contextually and not excessive).

And don't even me started on writing specs (ex. Rspec).

So sorry to say I am in complete agreement with psycopathicteen here.

[Drag]

I wish I knew that a change of 6dB was equivalent to halving or doubling the volume of something. That would've helped me understand certain PSGs a lot more easily.

(It's not exactly double or half, but it's close enough to where it doesn't matter for most applications)

[rainwarrior]

The equivalence 6db = 2x is usually within the tolerance of variation in the implementation anyway, so it really is just shorthand for "double" in a lot of documentation.