What should you really learn?

[Gachr]

Hi, there are very many topics like that, also a few explaining those things. I decided to make my own, share my few years of programming experience.

 

The most important question is - what do you want to do?

Game Development

I'll tell you straight away - if you want to get a job in game development, it will be very difficult. There are very few jobs, which require versatile skillsets. You can still manage to get one of course, or learn game dev just as a hobby - it's still great! You can learn a lot about programming making games. Even if you want to solely be a programmer, 3D modelling and 2D graphics are quite important - it will be difficult to make even a small game without those by yourself. As for languages - there are just so many different languages. Please skip to the Generic Languages - learn something like that, and then start using an engine. Unity that uses C# and Godot that uses its own language, along C# are very popular choices. Honourable mention to Unreal, but I don't think it's a very good first engine). You might think that you should learn C# for game development, and it wouldn't be a bad choice at all. However, you don't really need that much C# knowledge to start developing games, and the core language can be quite overwhelming.

Mobile Development

Apps are everywhere, so mobile is a good way to go. Quite a lot of jobs - still not as many as for web developers, but it should be fairly easy to get a job as a mobile dev. And hey - you can always freelance easily or make money on your own apps! iOS development is usually done in Swift, Apple's own language. It's a language for the Apple ecosystem, so if you don't have a mac, it's not a good idea to go into iOS development. Not only because of the language itself, but also you actally need a mac to develop and test those apps. Windows Phone uses C#, but who cares For Android, the generic option is Java. Again, Java can be quite overwhelming, so keep that in mind. There are, however frameworks that allow you to create an app once, and make it run on multiple machines. A very popular choice is one called Xamarin, that uses C#. It uses native toolkits for creating apps, so your apps will look very good no matter the platform. This is the general outline for mobile development. You can also create apps with JavaScript, but this is a route that I wouldn't advise you to go unless you are a web developer already.

Websites!

If you want to learn web development, you need to learn those things that you've heard of so many times - HTML and CSS. Many people think that coding in HTML and CSS is programming, but it's not. It's just an additional asset that's required if you want to create websites. You won't learn the same concepts as with programming language. The thing specific to creating websites on the front end (more on that later) is that you can do those only in one language - JavaScript. JS is a language that's capable of many great things, but websites are its origin. Once you learnt those three things - the huge world of web development is open to you!
Front-end vs Back-end

You might've heard those terms before. A long time ago, websites weren't too capable - there were some more complex ones indeed, but the same techniques were used. The web got so huge that the separation arose... well, it was always there to some extend, but right now the gap is quite wide. What I talked about above, is front-end development, so it's creating interfaces. However, if you want to create fully fledged websites that connect to databases, you need the "back end". Back end is the server logic that does everything behind the scenes. Nowadays, backend isn't limited to websites only. Using back-end languages, you can create something called an API, that lots of different clients can connect to - your website indeed, but you can also connect through a mobile app! Well, say you got a job at BMW - you could even create APIs for cars! APIs are intefaces that anything connected to the internet can connect to. They are responsible for all kinds of processing of data and files. So - should you go for front end or back end? Well, try both! For a lot of backend jobs, you will have to learn HTML, CSS and possibly JS anyway - it's also very good to know how they work. Then you can pick your favourite. There are lots of jobs for both, I'm working as a front end React developer, but I can do both myself. There is really great breakdown of what you have to learn about web development (both front and back) over here, don't get overwhelmed tho, I will also explain those things down the line: https://github.com/kamranahmedse/developer-roadmap

Front-end

You already learnt the basics. The very important thing is that you should learn the pure JavaScript language, don't jump into any libraries, frameworks or any other trendy stuff. As a JS developer, I can confirm that the core JS language is pretty terible it's difficult, but if you learn it very well, you'll be a much better web developer than a lot of other candidates! Once you mastered JavaScript, you should learn a framework. It's not somethig that you should specialise in - yes, there are lots of React, Angular etc jobs, but they are just tools. It's very important that you are a good JS developer, and other things will be just additional assets. Things that will come in very handy are npm and sass, make sure to learn those! You have a much more in depth description of all those technologies in the link above.

Back-end

This is where the real fun begins. Historically, PHP is the behemoth for websites. Lots of people hate on PHP, some reasons are very valid, some aren't, but it's not a necessarily bad language. No matter what you think about PHP, it will be the best choice for creating back-ends for websites. For other things? Not that much, but it's decent nonetheless. Thing is, no matter what language is your favourite, PHP has the popularity, maturity and lots of developers! There are lots of jobs, and lots of different tutorials and documentation. If you go with PHP, you might struggle a little, but it's a very solid option.

But, nowadays, you can use pretty much anything for backends.

Java is huge for back-ends, especially in the enterprise. It is a huge ecosystem, so you will really need to dive into it. However, if you are good at Java, you can create lots of different wonderful things. Don't let anyone tell you that it's dying - it's not. C# is also quite large, not as large as Java, but it's also a very good option. Be aware though, that C# development isn't very popular in some parts of the world, and that you will be partly locked to Microsoft ecosystem.

Python and Ruby are very decent choices for back end development too. There are lots of jobs, the languages are powerful... You can't really go wrong with those. They are easy to learn, but aren't to specific to web development as PHP, you can do lots more things with them.

Then, there is Node.js, which allows you to write server code with JavaScript. Like I said before, JS is super versatile. Node.js has an ecosystem and way of running that's quite unusual, but it's a solid option for front-end web developers.

You can create backends with pretty much any language, but the ones above are the most popular and easiest ones. There are lots of tutorials, programmers and jobs. If you want to create backends with something else - please go ahead! But for the beginner, the above options are the good ones. More info about back end development is available in the infographic I linked to above.

 

Generic Options

If you still aren't sure what you want to do, or just want to try programming - there are two options you can't really go wrong with.

The first one is Python, which is recommended A LOT. Personally? I think it's overrated. It is easy to learn, and you can do lots of things with it - so if you want to learn by doing, it's the perfect match. However, it is not a remedy and perfect solution for everything. So yes, if you want to write scripts and do cool stuff - choose Python!

The other one is C. I will tell you right away, that you won't do too many things with it, especially cool things. However, if you learn C well, you will know lots of concepts that are essential to programming and computer science. In my opinion, I think that every programmer should know C more or less. It just gives you lots of useful skills and insights.

You might ask - why not C++? C++ is also a very useful language, but it's probably the most difficult one out all the ones that I've mentioned. Learning it can be, and most likely will be very overwhelming. However, C++ is just an extension of C. So even if your goal is to do things with C++, it's a good idea to learn C first, and then learn what's new in C++.

 

Yes, so the post is much longer than I wanted it to be, there are still a lot of things to talk about, but I have to sleep I'll most likely extend this topic, please share your suggestions and ask me questions below! The last question is "where to learn it?". There are lots of different resources, but my tips are not to use pretty websites like codecademy, because you'll get lazy because of them. Once I made a long topic on why those websites aren't that good. Look for tutorials, but don't be afraid to look into official documentation, and most importantly - experiment! That's the greatest way to learn.

[Techicolors]

nice post. i am currently self-learning web development, pretty neat thus far. i would like to reference freecodecamp here. it's not comprehensive, but it's a very nice taste of what it's about. 

 

you mention you're a react developer. have you any pointers or guides for someone learning react? 

[Gachr]

1 minute ago, Technicolors said:

nice post. i am currently self-learning web development, pretty neat thus far. i would like to reference freecodecamp here. it's not comprehensive, but it's a very nice taste of what it's about. 

 

you mention you're a react developer. have you any pointers or guides for someone learning react? 

Yes freecodecamp is also one of those "pretty websites" that I mentioned, but it's actually really good, I tried it.

All it took me to learn React was the official docs. Sometimes the easiest solutions are the best React code can differ quite a lot, so make sure you research features a lot (like class properties) and read a lot of the code that's already out there.

[reniat]

1 hour ago, Gachr said:

No matter what you think about PHP, it will be the best choice for creating back-ends for websites

I'm not a web developer, but I think "best choice" is quite a stretch. I know a LOT of development is shifting to React, which was made specifically to uplift facebook from its php backend to its more modern node.JS backend. I'm not saying php is "bad", but I do not think it's the direction the industry is heading. I know for a fact our company (a super large enterprise software company which is definitely not "bleeding edge"), much prefers node.js, ruby on rails, and spring MVC for back end experience when hiring.

 

Again, i'm not a web dev so I could be super wrong, but what little web dev stuff I have seen in passing has made it seem like php might not be the best investment if you only had to learn 1 backend framework and were just getting into the industry.

[bowrilla]

Good idea though I can't really agree on several aspects.

Game Development

You totally missed the increasing amount of HTML5 and/or WebGL games for browsers and mobile devices. If you're aiming for browser based WebGL games you will have to rely on Javascript. You can basically create games with every single language around. True, Unity and C# has a huge market share so if you want to get a job as a game developer it's not a bad choice. Cryengine is also available on a free full source code license with 5% royalties after your first 5k. If you're aiming at most other engines around you most likely won't be able to get around C++. It's not just the Unreal engine that's written in C++ (or at least partly written in it). 

It's not a good way to start your coding career though. It's a very complex field that combines lots and lots of skills if you want to go past generic stuff. Placing a few assets in Unity or Unreal and moving some blocks around can get you nice results but you're far from being an actual game developer. As soon as you want to go deeper into 3D you will need profound knowledge of math since you'll be forced to handle geometric operations. Performance is an issue so your knowledge of your language of choice should be good enough to optimize the code. You need to learn how to handle APIs like OpenGL, DirectX or Vulcan and their approaches to shaders. There's physics involved and lots of 3D and 2D art. This is not your first step when learning how to code but of course you can choose a language that will enable you to approach game development later on on a professional level. Basically: if you want to develop games for desktop games: C# or C++. If it's just a hobby go with whatever language that pleases you.

 

Mobile Development

If you want to develop for all platforms around you either go the Javascript route which is a viable option for low to medium power hungry tasks. Beyond that it's again C++. While iOS will demand some use of Objective C or Swift in order to interface with system events and to make display calls but the rest can be done in C++. 

 

Front- vs Backend

Just as an addition to make it a bit clearer: the backend is where your data is handled and the frontend is the direct interaction layer between users and the data that got or gets send to them. Think of a blog system: all information are stored on the server. When a visitor opens that blog the visitor's browser will send a request to the server. The server authenticates the visitor, looks for the correct page and sends it back. The browser will then render it. Let's say there's a sort button on the blog that sorts all entries by a certain tag. This can be done within the browser on the frontend side. The already available data just gets pushed around on the screen, the backend/server isn't involved in this. It's possibe to let the frontend make a request to the server for more information though. There's no point in displaying 10.000s of blog posts on one page. You will most likely only display a certain amount and offer to go to more pages of results. You could of course make a full request and just ask for a whole new page but thats inefficient. The frontend can dynamically ask for the next 10/100/xxx results, the server/backend answers and the frontend just updates certain parts. A classic scenario for the backend is authentication. 

Backend development

True, PHP is the biggest player around. The language is ugly on overloaded with legacy stuff and many many many illogical things. Wordpress for example is written in PHP, so if you want to develop Wordpress pages you will have to user PHP. However the biggest challengers nowadays are Python and Javascript. Ruby used to be popular but the hype is kind of over. The biggest advantage of Javascript and node.js is: you only need one language for front- and backend development. There's no way around it for frontends so why not using it for the backend as well? The community is big, there are many tutorials around and it scales better. On the other hand Python is better for CPU heavy stuff. If you already know Python it's a good point to start but you still need to learn Javascript for your frontend. There are jobs for PHP, Python and Javascript developers around and salaries are pretty decent. Java is only really used in bigger enterprise solutions and the biggest issue is Java itself (imho).

 

Totally missing out:

 

IoT, Robotics, embedded systems

It just is C. As soon as you're trying to program micro controllers you just go for C – or if you're a masochist x86 Assembler. While some Assembler knowledge can come handy in order for developers to understand system architecture and advantages and disadvantages of different techniques, you just don't use it like 99.9999% of the time.

 

[vorticalbox]

6 hours ago, reniat said:

I'm not a web developer, but I think "best choice" is quite a stretch. I know a LOT of development is shifting to React, which was made specifically to uplift facebook from its php backend to its more modern node.JS backend. I'm not saying php is "bad", but I do not think it's the direction the industry is heading. I know for a fact our company (a super large enterprise software company which is definitely not "bleeding edge"), much prefers node.js, ruby on rails, and spring MVC for back end experience when hiring.

 

Again, i'm not a web dev so I could be super wrong, but what little web dev stuff I have seen in passing has made it seem like php might not be the best investment if you only had to learn 1 backend framework and were just getting into the industry.

You're not wrong, I build web based finance software (back end but also help out on the front end) and node is was it's at.

 

It's not the be all be to back end development but Netflix recently decided to move most of their code over to node.

 

More advanced things to get into are docker containers and serverless. 

[Gachr]

7 hours ago, reniat said:

I'm not a web developer, but I think "best choice" is quite a stretch. I know a LOT of development is shifting to React, which was made specifically to uplift facebook from its php backend to its more modern node.JS backend. I'm not saying php is "bad", but I do not think it's the direction the industry is heading. I know for a fact our company (a super large enterprise software company which is definitely not "bleeding edge"), much prefers node.js, ruby on rails, and spring MVC for back end experience when hiring.

 

Again, i'm not a web dev so I could be super wrong, but what little web dev stuff I have seen in passing has made it seem like php might not be the best investment if you only had to learn 1 backend framework and were just getting into the industry.

Poor wording on my side. What I meant was that it is the best choice for beginners, because of its popularity, it being web-oriented and simple in a comparison with Node's async nature for example. I'll correct it.

 

7 hours ago, bowrilla said:

Good idea though I can't really agree on several aspects.

Game Development

You totally missed the increasing amount of HTML5 and/or WebGL games for browsers and mobile devices. If you're aiming for browser based WebGL games you will have to rely on Javascript. You can basically create games with every single language around. True, Unity and C# has a huge market share so if you want to get a job as a game developer it's not a bad choice. Cryengine is also available on a free full source code license with 5% royalties after your first 5k. If you're aiming at most other engines around you most likely won't be able to get around C++. It's not just the Unreal engine that's written in C++ (or at least partly written in it). 

It's not a good way to start your coding career though. It's a very complex field that combines lots and lots of skills if you want to go past generic stuff. Placing a few assets in Unity or Unreal and moving some blocks around can get you nice results but you're far from being an actual game developer. As soon as you want to go deeper into 3D you will need profound knowledge of math since you'll be forced to handle geometric operations. Performance is an issue so your knowledge of your language of choice should be good enough to optimize the code. You need to learn how to handle APIs like OpenGL, DirectX or Vulcan and their approaches to shaders. There's physics involved and lots of 3D and 2D art. This is not your first step when learning how to code but of course you can choose a language that will enable you to approach game development later on on a professional level. Basically: if you want to develop games for desktop games: C# or C++. If it's just a hobby go with whatever language that pleases you.

 

Mobile Development

If you want to develop for all platforms around you either go the Javascript route which is a viable option for low to medium power hungry tasks. Beyond that it's again C++. While iOS will demand some use of Objective C or Swift in order to interface with system events and to make display calls but the rest can be done in C++. 

 

Front- vs Backend

Just as an addition to make it a bit clearer: the backend is where your data is handled and the frontend is the direct interaction layer between users and the data that got or gets send to them. Think of a blog system: all information are stored on the server. When a visitor opens that blog the visitor's browser will send a request to the server. The server authenticates the visitor, looks for the correct page and sends it back. The browser will then render it. Let's say there's a sort button on the blog that sorts all entries by a certain tag. This can be done within the browser on the frontend side. The already available data just gets pushed around on the screen, the backend/server isn't involved in this. It's possibe to let the frontend make a request to the server for more information though. There's no point in displaying 10.000s of blog posts on one page. You will most likely only display a certain amount and offer to go to more pages of results. You could of course make a full request and just ask for a whole new page but thats inefficient. The frontend can dynamically ask for the next 10/100/xxx results, the server/backend answers and the frontend just updates certain parts. A classic scenario for the backend is authentication. 

Backend development

True, PHP is the biggest player around. The language is ugly on overloaded with legacy stuff and many many many illogical things. Wordpress for example is written in PHP, so if you want to develop Wordpress pages you will have to user PHP. However the biggest challengers nowadays are Python and Javascript. Ruby used to be popular but the hype is kind of over. The biggest advantage of Javascript and node.js is: you only need one language for front- and backend development. There's no way around it for frontends so why not using it for the backend as well? The community is big, there are many tutorials around and it scales better. On the other hand Python is better for CPU heavy stuff. If you already know Python it's a good point to start but you still need to learn Javascript for your frontend. There are jobs for PHP, Python and Javascript developers around and salaries are pretty decent. Java is only really used in bigger enterprise solutions and the biggest issue is Java itself (imho).

 

Totally missing out:

 

IoT, Robotics, embedded systems

It just is C. As soon as you're trying to program micro controllers you just go for C – or if you're a masochist x86 Assembler. While some Assembler knowledge can come handy in order for developers to understand system architecture and advantages and disadvantages of different techniques, you just don't use it like 99.9999% of the time.

 

Thanks a lot for the suggestions! I'll include them in the original post later today. Although, I think that stuff like JS game dev is more of a path for people that already know the web, and "native" choices are better.

[MyName13]

No CS, information security, artificial intelligence, embedded systems etc.?

[Unimportant]

14 hours ago, bowrilla said:

IoT, Robotics, embedded systems

It just is C. As soon as you're trying to program micro controllers you just go for C – or if you're a masochist x86 Assembler. While some Assembler knowledge can come handy in order for developers to understand system architecture and advantages and disadvantages of different techniques, you just don't use it like 99.9999% of the time.

x86 is not widely used in the embedded world. On smaller micro-controllers and similar, assembler is used fairly often. Either to manually optimize for size (being able to use the 50 cent cheaper, smaller memory, micro adds up when a million units are going to be built) or to debug. Often the high level constructs that guard against bugs are not available on these platforms and one has to go in and manually check the assembly code to see if things turned out as intended. An example would be the unavailability of mutexes or similar constructs that guard against races and atomicity bugs. The only way to make sure the final instructions line up in a safe way is to go in and check.

 

Imo, a knowledge of assembler (and the low level systems knowledge that comes with it) is a boon and should not be taken too lightly. The world is being flooded with high-level programmers as if they're being cranked out of a assembly line. If you want something that sets you apart from the next million guys and gals, assembler is a good start. All those million others will be calling on you when their high level construct does not behave the way they tought it would because the demons of the actual machine underneath came out. I've seen it happen often, so I'll say it again: You cannot hide from the actual hardware underneath forever.

[Mira Yurizaki]

29 minutes ago, Unimportant said:

x86 is not widely used in the embedded world. On smaller micro-controllers and similar, assembler is used fairly often. Either to manually optimize for size (being able to use the 50 cent cheaper, smaller memory, micro adds up when a million units are going to be built) or to debug. Often the high level constructs that guard against bugs are not available on these platforms and one has to go in and manually check the assembly code to see if things turned out as intended. An example would be the unavailability of mutexes or similar constructs that guard against races and atomicity bugs. The only way to make sure the final instructions line up in a safe way is to go in and check.

If you don't trust your compiler tools, you may as well skip C altogether and just write the whole thing in assembly.

 

And in my mind, if you need locks in the form of mutexes and whatnot, you may need to rethink your system design. I managed to build reasonably complicated apps for embedded systems without the need of such. At least on the application level. The framework may have had it, but that was developed by someone who was far smarter than me and knew what they were doing (hopefully).

29 minutes ago, Unimportant said:

Imo, a knowledge of assembler (and the low level systems knowledge that comes with it) is a boon and should not be taken too lightly. The world is being flooded with high-level programmers as if they're being cranked out of a assembly line. If you want something that sets you apart from the next million guys and gals, assembler is a good start. All those million others will be calling on you when their high level construct does not behave the way they tought it would because the demons of the actual machine underneath came out. I've seen it happen often, so I'll say it again: You cannot hide from the actual hardware underneath forever.

I think knowing about it and how to write assembler programs is nice, but I don't think it's a skill that anyone really looks for unless you're into extremely high-performance coding and for some reason the compiler you're using sucks at translating code into a decent amount of assembly.

 

The only time I ever had to write assembly language code was because I had to modify a microcontroller's boot code before it initialized itself to jump into a C application. Any other use of assembly was frowned upon because the C code was fast enough and using assembly language provided no extra benefit. But do I think that bit is what gives me an edge in the world? No. Any code monkey who spent an hour on Wikipedia and the ARM assembly manual (which is the architecture I was using) could've figured it out.

[Unimportant]

50 minutes ago, M.Yurizaki said:

If you don't trust your compiler tools, you may as well skip C altogether and just write the whole thing in assembly.

A C compiler is free to reorder/optimize as long as the compiler *thinks* it will not change the result. Sadly, that does lead to problems in the real world sometimes. I've seen EEPROM unlock sequences being optimized away and interrupt enable/disable instructions being reordered in problematic ways just to name two. Some of those things can be blamed on poor compilers (the first one was caused by "volatile" not working as intended on that platform's  C compiler). But all of these errors can only be seen by looking at the generated assembler. There's a whole world of "small" devices out there besides "large" platforms such as x86/ARM/etc, and poor compilers are sadly not uncommon. Saying that you just write everything in assembler is probably a overreaction tough.

50 minutes ago, M.Yurizaki said:

And in my mind, if you need locks in the form of mutexes and whatnot, you may need to rethink your system design.

Any non-trivial (and even trivial) micro-controller project uses interrupts, and then you have to deal with some form of locking/atomicity, and often you have to do it yourself because, as said, the high level constructs are unavailable on these platforms. You will then eventually run into problems like mentioned above.

50 minutes ago, M.Yurizaki said:

I managed to build reasonably complicated apps for embedded systems without the need of such. At least on the application level. The framework may have had it, but that was developed by someone who was far smarter than me and knew what they were doing (hopefully).

Perhaps some ppl's calling lies in being that framework writer ? If everyone keeps steering ppl away from the low level, how will they ever find out  ?

50 minutes ago, M.Yurizaki said:

The only time I ever had to write assembly language code was because I had to modify a microcontroller's boot code before it initialized itself to jump into a C application. Any other use of assembly was frowned upon because the C code was fast enough and using assembly language provided no extra benefit. But do I think that bit is what gives me an edge in the world? No. Any code monkey who spent an hour on Wikipedia and the ARM assembly manual (which is the architecture I was using) could've figured it out.

I think you're downplaying your knowledge too much. You clearly have a lot of low level knowledge, as evidenced by some of your other posts. Please consider the possibility that you may be using this knowledge subconsciously far more often then you think, and without it you might have a much tougher time at your daily activities.

 

Anyway, I'm just trying to show a different angle on the subject, in the end, everyone's mileage may vary.

[Mira Yurizaki]

25 minutes ago, Unimportant said:

A C compiler is free to reorder/optimize as long as the compiler *thinks* it will not change the result. Sadly, that does lead to problems in the real world sometimes. I've seen EEPROM unlock sequences being optimized away and interrupt enable/disable instructions being reordered in problematic ways just to name two. Some of those things can be blamed on poor compilers (the first one was caused by "volatile" not working as intended on that platform's  C compiler). But all of these errors can only be seen by looking at the generated assembler. There's a whole world of "small" devices out there besides "large" platforms such as x86/ARM/etc, and poor compilers are sadly not uncommon. Saying that you just write everything in assembler is probably a overreaction tough.

The way I see it, you trust what the compiler is doing until you run into a problem. The vibe I got from your post is to examine the outputted assembler frequently just to make sure the compiler did its job correctly. If I'm at that point, I may as well apply the mantra "if you want it done right, do it yourself."

Quote

Any non-trivial (and even trivial) micro-controller project uses interrupts, and then you have to deal with some form of locking/atomicity, and often you have to do it yourself because, as said, the high level constructs are unavailable on these platforms. You will then eventually run into problems like mentioned above.

I haven't had to deal with any form of locking because my designs specifically avoided it. Rather than have multiple entities trying to fight for a resource, a single entity controls the resource and everyone else just submits requests to it. On top of that, the systems I worked on had a real-time requirement and so predictability and determinism is crucial. Locking creates the problem where that determinism is diminished because you can't exactly predict who's going to get the resource next.

 

Not to mention a lot of what I worked on didn't even have something you could call an OS anyway.

 

Quote

I think you're downplaying your knowledge too much. You clearly have a lot of low level knowledge, as evidenced by some of your other posts. Please consider the possibility that you may be using this knowledge subconsciously far more often then you think, and without it you might have a much tougher time at your daily activities.

I only find it useful when it's necessary. Should I strive for perfection and optimization in my code? Sure, but I'm also a person who works on commercial products. My first goal is meeting the requirements of the customer. Finding ways to optimize the software should be spent after I have something to deliver, not before. If lower-level issues are a roadblock in getting to the requirements, then sure, I'll use what I know to figure out what to do. But so far it's rarely something that I've ever needed, even when I worked primarily in embedded systems.

 

Or at the least, my knowledge of lower level stuff is mostly in knowing how to read the programming manual of a particular piece of hardware in order to understand what to poke at it to make it do what I want and what to expect behavior wise. 99.99% if not 100% of the things described in these can be done in C.

[Unimportant]

25 minutes ago, M.Yurizaki said:

The way I see it, you trust what the compiler is doing until you run into a problem. The vibe I got from your post is to examine the outputted assembler frequently just to make sure the compiler did its job correctly.

That wasn't my intent. Off course you only investigate when there's a problem. But those problems will arise, and then you need the knowledge to be able to investigate.

26 minutes ago, M.Yurizaki said:

I haven't had to deal with any form of locking because my designs specifically avoided it. Rather than have multiple entities trying to fight for a resource, a single entity controls the resource and everyone else just submits requests to it.

I specifically mentioned interrupts as my main example. Try to imagine what happens when the single controlling entity gets interrupted while it's performing a non-atomic operation on some element when the interrupt routine is going to be be accessing that same element. The normal solution is to disable interrupts while the single controlling entity is working so it cannot be interrupted, and as said, I've had compilers reshuffle the disable interrupt instruction in a problematic way.

33 minutes ago, M.Yurizaki said:

Or at the least, my knowledge of lower level stuff is mostly in knowing how to read the programming manual of a particular piece of hardware in order to understand what to poke at it to make it do what I want and what to expect behavior wise. 99.99% if not 100% of the things described in these can be done in C.

And you never felt your low level knowledge being helpful for that ? In that you're able to understand how API's, libraries and whatnot work much better because you can better imagine what's actually happening under the hood? 

 

I think you're focusing too much on using assembler versus knowing assembler. I never claimed you have to actually write stuff in assembler (some touch-ups usually suffice). I'm talking about the importance of the low level knowledge assembly knowledge brings. In fact, it can be argued low level knowledge and assembler are one and the same thing. Are the mnemonics and little particulars of a certain platform really the key thing in assembly? Or is it the general knowledge of how a computer works at that level ? I'd argue the latter.

[Mira Yurizaki]

31 minutes ago, Unimportant said:

I specifically mentioned interrupts as my main example. Try to imagine what happens when the single controlling entity gets interrupted while it's performing a non-atomic operation on some element when the interrupt routine is going to be be accessing that same element. The normal solution is to disable interrupts while the single controlling entity is working so it cannot be interrupted, and as said, I've had compilers reshuffle the disable interrupt instruction in a problematic way.

The only area where I would see in the systems I worked with would have that problem was handled by the framework I used. And while I did learn about how the framework worked, I didn't really bother with going deep into its guts. By the time we used it, the framework was used by other applications from major companies so my confidence level in it was high.

 

On the app level, no interrupt is going to touch the the resource that controlling entity is working on. For example, if a UART is receiving data while the receiver handler is processing some previous message, the interrupt is going to use a statically allocated, but unused structure to fill in the message and send it on its merry way to the receiver handler to be processed. The structure is managed by the framework and the receiver handler isn't going to touch it until it's done with whatever is already on its plate.

 

The side point here is someone already invented a wheel that works. I'm not going to reinvent it.

Quote

And you never felt your low level knowledge being helpful for that ? In that you're able to understand how API's, libraries and whatnot work much better because you can better imagine what's actually happening under the hood? 

 

I think you're focusing too much on using assembler versus knowing assembler. I never claimed you have to actually write stuff in assembler (some touch-ups usually suffice). I'm talking about the importance of the low level knowledge assembly knowledge brings. In fact, it can be argued low level knowledge and assembler are one and the same thing. Are the mnemonics and little particulars of a certain platform really the key thing in assembly? Or is it the general knowledge of how a computer works at that level ? I'd argue the latter.

If this is the case, then I don't think it was necessary to bring up assembly in the first place. You don't need to know assembly of any sort to understand the inner workings of a processor. Some architectures hide details that if you thought the assembly code was how the processor worked, it would be harmful in trying to manually fine tune performance. As an example: https://blogs.msdn.microsoft.com/oldnewthing/20041216-00/?p=36973

 

However, I will agree knowing some things beyond the level of scope your software runs on is important, but I don't think it's important to dive into much detail beyond a layer or two below. For example, I don't think it's really important for say a web page developer to understand every little detail about the OSI Model. Since most of their work is in the application layer, they shouldn't really need to touch things like the Network or Data Link layers. At best, they may dive into the Presentation or Session layers. Maybe the Transport layer if only to know the difference between TCP and UDP, but that's about it. Anything else and they're not doing front-end work.

 

EDIT: If you feel that I'm being a bit hypocritical or something since I've apparently accumulated a knowledge of how things work at lower levels but saying it's not that important to know them, I also ask what the other person really wants to do and how much they really care about computer systems or whatnot. If they just want to build web pages using HTML, CSS, and JS, then fine. I'm not going to shove them Tanebaum's book on computer networks and tell them they need to read it. I'll just give them a book on HTML, CSS, and JS (which for the first two I recommend https://www.amazon.com/HTML-CSS-Design-Build-Websites/dp/1118008189/) But if working on websites grows an interest in how computer networks work, then I'll give them Tanebaum's book.

[Guest]

I'm nowhere near an expert but most actual Game Development Programming Jobs demand C++ knowledge. 
Objects are really good for games & C++ is pretty close to assembly giving pretty good performance. It's not assembly, that's why I emphasized before someone tells me I'm wrong. 
I also looked up a few internet Game Development jobs & they also require C++ oddly. (This was 2K games I believe in California.) 
An HR representative at a AAA company showed me some requirements for game development showing some Dutch Intern portfolios. The interns already created several games in Unity AND used hard DirectX to create their own game engines with external assets, physics and whatnot in 3D. 
There's mega amounts of competition. Even those that want to do 3D modelling or 2D modelling Drawing-you better make all your models & pictures as good if not better than the games you see on store shelves. People move companies all the time & you directly compete with them in job application. 
Art is objectively more difficult to get into but I thought I'd just append your listing. 
Game companies don't typically care what engine nor language you use to make games. They want some proven knowledge of C++ & some evidence that you can complete some kind of game if you're a programmer. (Too many disciplines to touch on all of them.) 

[Dat Guy]

I do most of my web and desktop development in C these days, so don't learn a purpose, learn a technique instead.

[Unimportant]

22 hours ago, M.Yurizaki said:

The only area where I would see in the systems I worked with would have that problem was handled by the framework I used. And while I did learn about how the framework worked, I didn't really bother with going deep into its guts. By the time we used it, the framework was used by other applications from major companies so my confidence level in it was high.

 

On the app level, no interrupt is going to touch the the resource that controlling entity is working on. For example, if a UART is receiving data while the receiver handler is processing some previous message, the interrupt is going to use a statically allocated, but unused structure to fill in the message and send it on its merry way to the receiver handler to be processed. The structure is managed by the framework and the receiver handler isn't going to touch it until it's done with whatever is already on its plate.

 

The side point here is someone already invented a wheel that works. I'm not going to reinvent it.

Yes, but this isn't about you or me. As said, what if whoever reads this threads wants to be become the framework writer but does not know what he wants yet? Everyone here keeps pushing ppl away from the low level. Someone needs to write the things you build on, and it's never a waste of time to learn how the foundations you build upon work. In fact, when I interviews job applicants that show too much disinterest in the lower levels they get moved down the list. Wanting to know how computers work under the hood work should be natural for programmers imho, and shows you have the required passion.

 

22 hours ago, M.Yurizaki said:

If this is the case, then I don't think it was necessary to bring up assembly in the first place. You don't need to know assembly of any sort to understand the inner workings of a processor.

Imho it's the fastest way to learn (and remember!) how a CPU does it's business. You will bump into all the little details of how a program is executed at the lowest level and learn everything in a relevant context. You can read all the theory you want but actually putting it into a practice is when you really learn.

 

 

 

[Mira Yurizaki]

34 minutes ago, Unimportant said:

Yes, but this isn't about you or me. As said, what if whoever reads this threads wants to be become the framework writer but does not know what he wants yet? Everyone here keeps pushing ppl away from the low level. Someone needs to write the things you build on, and it's never a waste of time to learn how the foundations you build upon work. In fact, when I interviews job applicants that show too much disinterest in the lower levels they get moved down the list. Wanting to know how computers work under the hood work should be natural for programmers imho, and shows you have the required passion.

 

Imho it's the fastest way to learn (and remember!) how a CPU does it's business. You will bump into all the little details of how a program is executed at the lowest level and learn everything in a relevant context. You can read all the theory you want but actually putting it into a practice is when you really learn.

The only thing I can think of where knowing something beyond what you're expected to know just for the job at hand is it shows you're willing to learn things that are related but outside of what's expected of you. Meaning you're willing to grow. But it doesn't have to be specifically just lower-level things.

 

I mean, if I wanted to take this "you have to know the fundamentals" to a logical extreme let me ask this: do you know how MOSFETs work? Can you resolve a circuit? I had college level courses in electrical engineering including circuit analysis and transistor theory. Does that help me at all in software development? No. But it's certainly a fundamental aspect of how computers work because it builds the logic gates that drive the system.

 

If anything, the most I'd expect programmers to know is a general idea of how a computer works and what the components in it do at a higher level. I don't expect to explain in detail what caching does or what a super-scalar pipeline is. Nor do I expect them to "compile" a simple C program by hand.

Edited May 31, 2018 by M.Yurizaki

[Unimportant]

33 minutes ago, M.Yurizaki said:

do you know how MOSFETs work? Can you resolve a circuit?

Yes, I do, we design the electronics for our embedded products ourselves.

 

But let's agree to disagree, anyone interested has seen both views by now and can decide for him/her-self.

[Mira Yurizaki]

2 minutes ago, Unimportant said:

Yes, I do, we design the electronics for our embedded products ourselves.

 

But let's agree to disagree, anyone interested has seen both views by now and can decide for him/her-self.

Alright, but there was one more point I wanted to share.

 

If it were me who was hiring a candidate, I would rather know what they've done, not what they know. It's more meaningful to me to see "I worked on X project that greatly helped the compan's Y product" than "I know ARM assembly." What they've done also implies what they know.

[Unimportant]

5 minutes ago, M.Yurizaki said:

Alright, but there was one more point I wanted to share.

 

If it were me who was hiring a candidate, I would rather know what they've done, not what they know. It's more meaningful to me to see "I worked on X project that greatly helped the compan's Y product" than "I know ARM assembly." What they've done also implies what they know.

Off course, but I'm sure you know the drill, part of the talk is to gauge the applicants character.