How can I stop being mediocre?

[Seasoft]

I feel like I am running around in circles. I have never really coded as a regular routine or I would be interested in coding whateva for a few days and then go a period with not even looking at programming-related media at all. I wish I could learn to be less mediocre in my approach. Do you have any pointers for direction? I believe it's very possible too that I overestimate my skills, especially since I attempted OS or system-related stuff before and then "parked" it as being too advanced

[Korona]

Practice.

There is no secret. People are not naturally gifted to write OSes either (although of course there is often some kind of predisposition for math, CS, natural sciences and/or engineering involved). I've been working on and off on OSDev for almost 15 years (according to the age of my profile here), and now I feel reasonably confident about what I am doing. But in the beginning, we were all happy to see a Hello World in 0xB8000 text mode after entering PM (well, at least those of us that started developing on x86).

[sj95126]

Something that has helped me is to sketch out on paper the next thing you're going to implement. That's good advice no matter what - it's not especially good practice to just start writing a block of code, though I do it all the time anyway. It's easy to fall into a pattern where you code for a while and get frustrated or lose interest, usually because you spent way too much time doing something fairly simple and made mistakes.

I find that by writing it down - diagrams, pseudo-code, and so forth - I get to see things in a different way, which keeps my interest, and when I've done that, I find myself eager to implement it. It's kind of a game - how good was the design? Can I make this work perfectly the first time?

I try to keep my code simple and straightforward. I'm not wild about overly complex compound statements. Sure, they might save a few bytes and a few clock ticks, but that's not worth the confusion of "why the heck did I do that?" down the road. The trade-off is that I always feel my code has an amateurish look to it. I don't mean so amateurish that I used an if-then-else as though I don't know how to use a ternary operator. It just looks too simple. Maybe that's the way you always view your own code.

But the advice is right - practice, practice, practice. And look at open source code for ideas. I don't mean copying their implementation, but to get a sense of the style and complexity factor.

[bzt]

Those are both good advice. One thing I've noticed is that successful people (developer or not) are also stubborn and presistent as hell. They never give up and they don't stop until they find a solution to a problem. They keep thinking about the issue in their sleep and even when they "take a bath".

Cheers,
bzt

[nullplan]

I try to keep my code simple and straightforward. I'm not wild about overly complex compound statements. Sure, they might save a few bytes and a few clock ticks, but that's not worth the confusion of "why the heck did I do that?" down the road. The trade-off is that I always feel my code has an amateurish look to it. I don't mean so amateurish that I used an if-then-else as though I don't know how to use a ternary operator. It just looks too simple. Maybe that's the way you always view your own code.

That's generally the mark of a great programmer. You should strive to express your ideas in ways that are easy to read. If it is hard to read, you are either doing something really clever or really stupid. And cleverness is in short supply, usually.

It is usually helpful to get the code size down. More lines are more of a burden on everything, but most importantly, on the people reading your code, including yourself. This is, of course, not generally true. It also depends on the complexity of those lines. For example, today I wrote this statement:

Code: Select all

is_tn = (is_tn & ~(1ul << i)) | ((is_tn >> (nfd - 1 + i)) & (1ul << i));

This statement has a bug in it. I don't know if you can see it without context. (In context, nfd is guaranteed to be larger than i.) But most of all, it just looks ugly, so I rewrote it:

Code: Select all

if (is_tn & (1ul << (nfd - 1)))
  is_tn |= 1ul << i;
else
  is_tn &= ~(1ul << i);

And boom, suddenly I know what is going on. This time, it is admittedly longer, but one should strive for more understandable code over "faster" code.

I do like ternary operators if they can make an idea appear more clearly. I often fix up code like

Code: Select all

if (some_condition)
  set_color(foo, RED);
else
  set_color(foo, GREEN);

with a ternary operator, because I want it to be clear that a color is being set. And after disentangling a web of logical operators today, I really don't get why the ternary operator gets singled out so often. The logical operators can do just as much damage if their number grows large enough.

And look at open source code for ideas.

Oof, those can be really hit or miss. Some open source projects, like musl, can be downright therapeutic, yes, but some others not so much. Busybox seems to be making an effort, though. newlib on the other hand is really great if you're in the mood for some horror and you misplaced your Lovecraft collection.

They keep thinking about the issue in their sleep and even when they "take a bath".

If I had a penny for every time I solved a bug on the toilet... I'd have tuppence!

[sj95126]

And look at open source code for ideas.

Oof, those can be really hit or miss.

I should have been more specific that looking at open source is sometimes about what NOT to do.

[dseller]

Those are both good advice. One thing I've noticed is that successful people (developer or not) are also stubborn and presistent as hell. They never give up and they don't stop until they find a solution to a problem. They keep thinking about the issue in their sleep and even when they "take a bath".

Cheers,
bzt

I agree with bzt. In my opinion, anyone can learn to read and write a programming language, and even make some software. It takes a lot more than that to become a great developer though. And not everybody can do that.

[Korona]

I agree with bzt's comment about persistence. However, do not worry if you do not think about OSdev in your sleep .

It is true though that many people do not realize that developing an OS is not only somewhat hard but also quite lengthy. Even a great programmer won't be able to develop a meaningful general purpose OS without continuous development effort (over many months and years). There is a lot of maintainance and iteration involved.

[0b1]

Keep your mind on what you are trying to achieve until you have achieved it.

Avoid negative self-talk like 'mediocre' - it just demotivates. And doesn't give you any useful feedback that you could correct.

Above all don't give up until you are done or out of options. Humans are creative and the latter happens less than you think.

[gungomanj]

I think the issue that most people struggle with is perfectionism and self-chastisement, your first works will be abysmal (I still cringe at the code I wrote years ago) but overtime you will get better and solve more challenges. Another thing is passion, you must love solving difficult problems and dealing with setbacks, and have some programming/tech interest already. I got into RISC-V osdev by using knowledge I already had from webdev, linux system administration, C I was taught in high school, assembly tutorials I saw on youtube etc. It's easier when you have a base. A book I would recommend you reading is the linux programming interface which introduces you to kernel concepts and even where you can read C code to understand certain things like IPC. You also have things like 8086emu and other simpler processors and emulators like for 8051 where you can dip your feet in.