8

So I have this problem, it may be my OCD (i have OCD it's not severe.....but It makes me very..lets say specific about certain things, programming being one of them) or it may be the fact that I graduated college and still feel "meh" at programming. Reading This made me think "OH thats me!" but thats not really my main problem. My big problem is....anytime im using a high level language/API/etc. I always think to myself that im not really "programming".

I know I know...it sounds stupid. But Like I feel like....if i can't figure out how to do it at the lowest level then Im not really "understanding" it. I do this for just about every new technology I learn. I look at the lowest level and try to understand it. Sometimes I do.....most of the time I don't, I mean i've only really been programming for 4 years (at college, if you even call it programming.....our university's program was "meh").

For instance I do a little bit of embedded programming (with the Atmel AVR 8bits/Arduino stuff). And I can't bring myself to use the C compiler, even though it's 8 million times easier than using assembly......it's stupid I know...

Anyone else feel like this, I think it's just my OCD that makes me feel this way....but has anyone else ever felt like they need to go down to the lowest level of the language to even be satisfied with using it?

I apologize for the very very odd question, but I think it really hinders me in getting deep seeded into a programming language and making a real application of my own. (it's silly I know)

Improve this question
4
  • 2
    What does "meh" mean?
    – Mike Dunlavey
    Mar 7, 2011 at 21:53
  • 2
    dictionary.reference.com/browse/meh
    – Kaz Dragon
    Mar 8, 2011 at 10:30
  • 3
    Why does your "OCD" stop at assembly? That's not really programming, writing binary machine code is. Then again, that's not programming either, writing microcode is. On second thought, that's not programming -- writing the CPU in a HDL is. Then again, not doing your own placing-and-routing isn't real programming, either. Even if you did do your own, you didn't design the transistors. Had you designed the transistors, it's not really programming as you didn't dig up the silicon yourself. See where I'm going with this?
    – Aidan Steele
    Mar 10, 2011 at 2:40
  • 6
    I find it rather ironic that a "Reinventing the wheel" question got marked as a duplicate...
    – Bobson
    Jun 5, 2013 at 18:31

6 Answers 6

Reset to default
11

In college we started at the low level. Write your own linked list, dictionary, red-black tree, merge/quick sort,... algorithms and structures. Once we knew them it was OK to use the standard libraries.

And similar with languages. We started with C and once you know how pointers work it's easier to see how, for example Java works.

In short, I think it's useful to implement it once to see how it works. From there on just go ahead and use the standard implementations. They're tested by thousands of users, they'll contain less bugs then your own code.

Improve this answer
10

if i can't figure out how to do it at the lowest level then Im not really "understanding" it.

It's true you not fully understanding it. But thats OK. Understanding the code is not the goal...

The Goal is to get the Job Done. Only reason to understand how it works is because that help you get the Job done (and get it done right).

You need to adjust your thinking, otherwise You will be that guy Joel talks about who is smart but never gets anything done.

Improve this answer
1
  • 1
    Not fully understanding things is common in all professions. Doctors prescribe aspirin even though no one knows how it works (last time I checked anyway). We install lightning rods though physicists still don't fully understand lightning (a lightning expert told me that a few days ago). The challenge for intelligent people is not to understand, but to make things work despite not understanding the inner details.
    – DarenW
    Mar 25, 2011 at 22:45
5

That's not OCD. Indeed, it's not anything like OCD.

That's NIH. Not Invented Here.

It's a really bad habit, but many people seem to enjoy it.

Improve this answer
2

Possibly a worry over abstraction?

Higher level languages attempt to introduce a greater level of abstraction to solve the underlying problem in as few conceptual steps as possible. In your case, it appears that you don't feel comfortable being shielded from the inherent complexity of the problem and so you want to address it at the lowest possible level of abstraction (or highest "concreteness").

Perhaps you need reminding that at some point the software must drive the hardware to make something physical occur (the concrete). One step back from that is the lowest level of abstraction available to you as a programmer. Once you accept that some form of abstraction is necessary in order to actually create software, then you can rise up and up into the higher levels of abstraction until you reach a point where you feel most comfortable.

Improve this answer
1

Have a read to Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels.

My point is that reinventing the wheel DOES make sense when you are doing it for learning purposes. It makes sense if it's (or will be) your main area of expertise. The internet is full of "don't reinvent the wheel", but sometimes it makes sense.

Improve this answer
2
  • would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange
    – gnat
    Jun 3, 2013 at 18:08
  • @gnat ha, didn't know about "Link only answers". My point (2 years ago!) is that reinventing the wheel DOES make sense when you are doing it for learning purposes. It makes sense if it's (or will be) your main area of expertise. The internet is full of "don't reinvent the wheel", but sometimes it makes sense.
    – Juan Delgado
    Jun 5, 2013 at 7:32
0

Test your low-level coding skills against higher-level languages/libraries by implementing the CRUD operations in a data structure in assembler, then C, then C#. Keep track of how long it took you to code each version (of course this assumes you are equally facile in each language). They run some tests to see the difference in speed between the versions. You might find the extra time it takes you to implement the lower-level versions is not worth the small difference in speed. Or even worse, you find that your higher level version is faster--oh the humanity!

There's nothing wrong with learning lower-levels. The trick is finding the balance between completing a project on time and providing decent performance.

Improve this answer