This post has actually been "baking" in the back of my mind for quite some time now. Initially I actually wanted to do a presentation with most of the content of this post based on some important open source project but I could not find the motivation to actually finish the presentation because it ended up being a bit complicated.
Also, this post is actually the result of me interacting with a few developers at the very beginning of their careers and also seeing the behavior of various students at university. So this post will be mostly about some of the obstacles that most people face in the beginning of their careers but not only this.
The first thing that comes in my mind is that people panic too fast when trying to learn something and actually stop trying, thinking and focusing on learning. I looked into this and I noticed several things. One of the most obvious thing is that people are scared of abbreviations or pompous words. And in this field you will notice them a lot. I think here some people try to appear more knowledgeable and more "expert" than they really are by using such words that sound really sophisticated when in reality they could have used much more simpler words which most people could relate to. Another thing is that people that are the beginning of their careers don't have the knowledge and expertise to tell if something that they are trying to learn is a hard or easy subject to learn by common programming standards.
The first example that comes in my mind here is when students learn in the first year of university C++ and in the following years C# or python. Most of them have the false assumption that what they learn in the beginning is actually easier to learn than the things in the following years. Which is far from true. By most standards python and C# are easier to learn and use than C++. In C# you don't have for example destructors, memory allocation, destructors and the built-in library is much more easier to use than the horrific C++ standard library. You can even look at the C++ specifications which are nearly double the size of the C# specifications. I too was guilty of this mistake. Python is even more easier to learn and it is a much more "clean" language than C++. Plus it doesn't have destructors, memory allocation and all that ugly low level stuff. I think it doesn't even have that virtual methods weird stuff with virtual method calls or whatever it is called.
Another example that comes into my mind are ORMs. People in university manage to learn SQL without too many problems but when suddenly they hear about "ORMs" they get scared and imagine it is something complicated. But the thing is ORMs are meant to replace sql and simplify database access. For a lot of scenarios they are meant to be easier and more simple to understand than sql. I mean they just fetch values from a table and populate the fields in an object that have the same name as the table's columns with those values. You might need to configure in some cases how to fetch, update or delete those values but you only need to learn like 10 important functions/methods for those which have at most 3 arguments. This is the case for entity framework core. A list class from a framework has around 5-6 important methods. So the basic use of an ORM isn't much more complicated than using list or vector class in C#. And some of the C++ "standard template library" stuff is much more horrible to use and understand than the list class in C# or an ORM for python. Still people get scared when they hear about ORM and give up. I remember the first time I heard about ORM I thought they were scary and ignored them until the final year of university.
The second thing that comes in my mind when I look at people who started working in this domain is the fact that they understand how they need to process some inputs to get the required output but they can't translate it into a concrete computer program. This is because they lack the required mindset. This is actually a bit tricky and hard to get a grasp of because it is a way of thinking. It pretty much means structuring your thoughts into a logical concrete process with precise steps which then can be easily translated into a computer program. I think this is called "pseudocode" when first learning programming. It is something that I did in high school and it is mostly forgotten later. Experienced developers grasp this so deeply that they do this intermediate step almost unconsciously without them even noticing it. But it requires a lot of exercise. It is actually pretty hard to get the hang of but you only have to do it once. After that you don't really have to learn anything new about this because it is pretty much universally applicable even if you change the programming language as long as it is not something radically different from what you already know. Even being aware of this and taking things step by step helps a lot.
The third thing that comes into my mind, is that beginners when they try to learn something new, they don't know how to differentiate between basic simple concepts related to what they are learning and more advanced concepts which are more difficult to understand. And when they run into the advanced concepts they get scared and demotivated, some of them eventually giving up. But they don't understand that the advanced concepts might be harder to understand even for more seasoned developers. Those hard concepts might be a solution to an even more complicated and hard problem. And not only that, but when learning something new, it might be based on other concepts that you need to learn beforehand. For example if you first learn an UI framework based on components, you surely need to know about collections because most of those components can have subcomponents grouped in collections. Or if you need to display a list of things, then of course you need to know about lists in that respective language or framework. Or if you need to develop a web api with a framework you also know some things about how the http stack works with headers and body, or the various kind of response codes that you can give to a client such as 400 series, 500 series and so on. A lot of technologies are built on top of one another and you need to understand the entire hierarchy to fully use it. Some people here might be unaware of this and come up to the false conclusion that they are incapable of learning that technology or concept when they actually should learn about the things that it depends on first. Those things might not be sufficiently explained giving the impression that the reader doesn't have the aptitude to understand it when they are explained just enough for people who already have some idea about them to remember them. Or they might not be explained at all.
As a general rule, when you learn about a new technology from a series of tutorials on the internet or anything else, the first bits of information that you can easily stumble upon in that tutorial should be the easiest things to learn. The deeper you have to dig to get some information the more advanced and complicated it might be. For example if you are reading a tutorial on the internet with several chapters, the final subsections of those chapters are probably the most complicated. Or the end of each subsection can contain the more advanced but less used things. Or if need to follow some additional links to get to that information then most likely it is some advanced stuff. Those kind of things are not required for basic usage of what you are trying to learn. And those advanced things are usually solutions to hard problems that you might stumble upon. To understand them properly you also need to understand the problem they address. For example in entity framework core in special circumstances when some features of the database you are using are not available, you can use the "FromSQL" method to manually pass the SQL query to the ORM bypassing its own SQL query generating mechanism. You can also pass parameters to your manually generated SQL.
The forth thing that comes into my mind can't be explained directly but rather with some analogies. Programming languages in the end can be considered languages just like common languages such as English, Romanian and so on. They can be used to express various things, concepts, processes etc. Now you might know the English language very well but that doesn't mean you can start reading English medical books and expect to understand them. Why, because they are from a specific domain which requires specialized knowledge beforehand. Its exactly the same with programming languages. They can be used to model a lot of things from a very wide range of domains for which a programmer can be more or less familiar with. In some cases you might develop the kind of application that you are familiar with as a user such as chat website. But in other cases you might develop financial applications which might require some specialized knowledge from that domain. Or you might end up developing an ecommerce website and you need to understand how some things work there such as discounts and prices. I worked on some medical related applications and there were a few concepts from the medical field that I had to understand to actually work on that application. In some cases the application do some very advanced stuff and of course it means as a developer that you also must be able to use it properly to be able to work on this. The first thing that comes into my mind are 3d graphic programs like Blender 3D. You can really expect to add new features to that open source software if you don't know things related to 3d graphics like modeling, texturing or rendering. This adds an extra layer of difficulty when developing application which sometimes people are not aware of and panic uselessly.
The fifth thing that comes in my mind is when a junior developer has his first interviews. A lot of times they end up being rejected. And most of the times, they don't really get a clear reason why they were rejected and what they lack exactly. So they start frantically learning a lot of things that they feel they lack when in reality they aren't always learning the right things which were actually required of them to pass the interview. They don't really know what they don't know and what they are supposed to know. In some cases they might even start learning some very complicated features of some technology that are not really required for the job. Even seasoned developers might have a bit of trouble understanding them or run into tricky roadblocks along the way. Now imagine a junior developer running into those things. He doesn't realize that other people struggle too with those things and starts to panic and to get discouraged. Plus he might run into the issues about learning a technology that I mentioned in a point earlier.
And if he manages to pass the interview he might land developing a project that requires quite a bit of domain knowledge to grasp properly. Again, he will probably panic and blame himself for being incapable of programming when actually he just stumbled on some applications with complex features and use scenarios. But the thing here is that the application that he is developing has a quite steep learning curve for users in general though this is not always the case. You might need to implement some very complicated domain knowledge to create some features that the user can easily use and understand.
I do admit, when a junior developer first tries to enter this field there are a lot of obstacles that he must overcome and it is really scary at first. But once he gets used to it and acquires all that he needs to know to do his job, we will never run into so many obstacles again. I mean when a junior developer starts his first job, he might need to improve his algorithmic/logical abilities, learn some more advanced features of a technologies and learn the domain knowledge of that application. But after that when moving to another job, he will already have acquired the necessary skills at least partially. And he won't have to learn the algorithmic skills again. Even if he has to learn some new technologies they might share enough similarities with those that he already knows that the learning process will be more easier.
Now the final thing which I actually noticed at me recently which is not to keep up with industry trends. A beginner might easily get trapped here learning some things that are becoming less and less used. Eventually those things become part of a niche market. And the junior developer will have less opportunities to change his job. He might get stuck at his current company for quite some time, even years. And in order to make the jump to some newer technologies he will have to start close to mid level with some new technologies all over again if he is unlucky even if at his current job he is actually a senior developer. If the job market for his skills is dwindling then the company can afford to pay him less knowing he doesn't many other places where to go. But its not always the case. I may be wrong here and people with these niche skills might be paid a LOT. Actually ran into some people that do get paid a lot for writing Fortran or Delphi code. But those language are used for mission critical services and applications which the company can't afford to lose.
Well, that's about it with this post. It turned out to be much more longer than I anticipated. I wanted to write this for a long time and the ideas just kept pilling up in the back of my head. I know some things might not pe 100% accurate but the general ideas seem pretty useful.
Also I should give credit to Roxana, someone I know personally, which had some experiences that inspired quite a few ideas on this post. Her name will forever be remember in this post and I thank her again.
Also, this post is actually the result of me interacting with a few developers at the very beginning of their careers and also seeing the behavior of various students at university. So this post will be mostly about some of the obstacles that most people face in the beginning of their careers but not only this.
The first thing that comes in my mind is that people panic too fast when trying to learn something and actually stop trying, thinking and focusing on learning. I looked into this and I noticed several things. One of the most obvious thing is that people are scared of abbreviations or pompous words. And in this field you will notice them a lot. I think here some people try to appear more knowledgeable and more "expert" than they really are by using such words that sound really sophisticated when in reality they could have used much more simpler words which most people could relate to. Another thing is that people that are the beginning of their careers don't have the knowledge and expertise to tell if something that they are trying to learn is a hard or easy subject to learn by common programming standards.
The first example that comes in my mind here is when students learn in the first year of university C++ and in the following years C# or python. Most of them have the false assumption that what they learn in the beginning is actually easier to learn than the things in the following years. Which is far from true. By most standards python and C# are easier to learn and use than C++. In C# you don't have for example destructors, memory allocation, destructors and the built-in library is much more easier to use than the horrific C++ standard library. You can even look at the C++ specifications which are nearly double the size of the C# specifications. I too was guilty of this mistake. Python is even more easier to learn and it is a much more "clean" language than C++. Plus it doesn't have destructors, memory allocation and all that ugly low level stuff. I think it doesn't even have that virtual methods weird stuff with virtual method calls or whatever it is called.
Another example that comes into my mind are ORMs. People in university manage to learn SQL without too many problems but when suddenly they hear about "ORMs" they get scared and imagine it is something complicated. But the thing is ORMs are meant to replace sql and simplify database access. For a lot of scenarios they are meant to be easier and more simple to understand than sql. I mean they just fetch values from a table and populate the fields in an object that have the same name as the table's columns with those values. You might need to configure in some cases how to fetch, update or delete those values but you only need to learn like 10 important functions/methods for those which have at most 3 arguments. This is the case for entity framework core. A list class from a framework has around 5-6 important methods. So the basic use of an ORM isn't much more complicated than using list or vector class in C#. And some of the C++ "standard template library" stuff is much more horrible to use and understand than the list class in C# or an ORM for python. Still people get scared when they hear about ORM and give up. I remember the first time I heard about ORM I thought they were scary and ignored them until the final year of university.
The second thing that comes in my mind when I look at people who started working in this domain is the fact that they understand how they need to process some inputs to get the required output but they can't translate it into a concrete computer program. This is because they lack the required mindset. This is actually a bit tricky and hard to get a grasp of because it is a way of thinking. It pretty much means structuring your thoughts into a logical concrete process with precise steps which then can be easily translated into a computer program. I think this is called "pseudocode" when first learning programming. It is something that I did in high school and it is mostly forgotten later. Experienced developers grasp this so deeply that they do this intermediate step almost unconsciously without them even noticing it. But it requires a lot of exercise. It is actually pretty hard to get the hang of but you only have to do it once. After that you don't really have to learn anything new about this because it is pretty much universally applicable even if you change the programming language as long as it is not something radically different from what you already know. Even being aware of this and taking things step by step helps a lot.
The third thing that comes into my mind, is that beginners when they try to learn something new, they don't know how to differentiate between basic simple concepts related to what they are learning and more advanced concepts which are more difficult to understand. And when they run into the advanced concepts they get scared and demotivated, some of them eventually giving up. But they don't understand that the advanced concepts might be harder to understand even for more seasoned developers. Those hard concepts might be a solution to an even more complicated and hard problem. And not only that, but when learning something new, it might be based on other concepts that you need to learn beforehand. For example if you first learn an UI framework based on components, you surely need to know about collections because most of those components can have subcomponents grouped in collections. Or if you need to display a list of things, then of course you need to know about lists in that respective language or framework. Or if you need to develop a web api with a framework you also know some things about how the http stack works with headers and body, or the various kind of response codes that you can give to a client such as 400 series, 500 series and so on. A lot of technologies are built on top of one another and you need to understand the entire hierarchy to fully use it. Some people here might be unaware of this and come up to the false conclusion that they are incapable of learning that technology or concept when they actually should learn about the things that it depends on first. Those things might not be sufficiently explained giving the impression that the reader doesn't have the aptitude to understand it when they are explained just enough for people who already have some idea about them to remember them. Or they might not be explained at all.
As a general rule, when you learn about a new technology from a series of tutorials on the internet or anything else, the first bits of information that you can easily stumble upon in that tutorial should be the easiest things to learn. The deeper you have to dig to get some information the more advanced and complicated it might be. For example if you are reading a tutorial on the internet with several chapters, the final subsections of those chapters are probably the most complicated. Or the end of each subsection can contain the more advanced but less used things. Or if need to follow some additional links to get to that information then most likely it is some advanced stuff. Those kind of things are not required for basic usage of what you are trying to learn. And those advanced things are usually solutions to hard problems that you might stumble upon. To understand them properly you also need to understand the problem they address. For example in entity framework core in special circumstances when some features of the database you are using are not available, you can use the "FromSQL" method to manually pass the SQL query to the ORM bypassing its own SQL query generating mechanism. You can also pass parameters to your manually generated SQL.
The forth thing that comes into my mind can't be explained directly but rather with some analogies. Programming languages in the end can be considered languages just like common languages such as English, Romanian and so on. They can be used to express various things, concepts, processes etc. Now you might know the English language very well but that doesn't mean you can start reading English medical books and expect to understand them. Why, because they are from a specific domain which requires specialized knowledge beforehand. Its exactly the same with programming languages. They can be used to model a lot of things from a very wide range of domains for which a programmer can be more or less familiar with. In some cases you might develop the kind of application that you are familiar with as a user such as chat website. But in other cases you might develop financial applications which might require some specialized knowledge from that domain. Or you might end up developing an ecommerce website and you need to understand how some things work there such as discounts and prices. I worked on some medical related applications and there were a few concepts from the medical field that I had to understand to actually work on that application. In some cases the application do some very advanced stuff and of course it means as a developer that you also must be able to use it properly to be able to work on this. The first thing that comes into my mind are 3d graphic programs like Blender 3D. You can really expect to add new features to that open source software if you don't know things related to 3d graphics like modeling, texturing or rendering. This adds an extra layer of difficulty when developing application which sometimes people are not aware of and panic uselessly.
The fifth thing that comes in my mind is when a junior developer has his first interviews. A lot of times they end up being rejected. And most of the times, they don't really get a clear reason why they were rejected and what they lack exactly. So they start frantically learning a lot of things that they feel they lack when in reality they aren't always learning the right things which were actually required of them to pass the interview. They don't really know what they don't know and what they are supposed to know. In some cases they might even start learning some very complicated features of some technology that are not really required for the job. Even seasoned developers might have a bit of trouble understanding them or run into tricky roadblocks along the way. Now imagine a junior developer running into those things. He doesn't realize that other people struggle too with those things and starts to panic and to get discouraged. Plus he might run into the issues about learning a technology that I mentioned in a point earlier.
And if he manages to pass the interview he might land developing a project that requires quite a bit of domain knowledge to grasp properly. Again, he will probably panic and blame himself for being incapable of programming when actually he just stumbled on some applications with complex features and use scenarios. But the thing here is that the application that he is developing has a quite steep learning curve for users in general though this is not always the case. You might need to implement some very complicated domain knowledge to create some features that the user can easily use and understand.
I do admit, when a junior developer first tries to enter this field there are a lot of obstacles that he must overcome and it is really scary at first. But once he gets used to it and acquires all that he needs to know to do his job, we will never run into so many obstacles again. I mean when a junior developer starts his first job, he might need to improve his algorithmic/logical abilities, learn some more advanced features of a technologies and learn the domain knowledge of that application. But after that when moving to another job, he will already have acquired the necessary skills at least partially. And he won't have to learn the algorithmic skills again. Even if he has to learn some new technologies they might share enough similarities with those that he already knows that the learning process will be more easier.
Now the final thing which I actually noticed at me recently which is not to keep up with industry trends. A beginner might easily get trapped here learning some things that are becoming less and less used. Eventually those things become part of a niche market. And the junior developer will have less opportunities to change his job. He might get stuck at his current company for quite some time, even years. And in order to make the jump to some newer technologies he will have to start close to mid level with some new technologies all over again if he is unlucky even if at his current job he is actually a senior developer. If the job market for his skills is dwindling then the company can afford to pay him less knowing he doesn't many other places where to go. But its not always the case. I may be wrong here and people with these niche skills might be paid a LOT. Actually ran into some people that do get paid a lot for writing Fortran or Delphi code. But those language are used for mission critical services and applications which the company can't afford to lose.
Well, that's about it with this post. It turned out to be much more longer than I anticipated. I wanted to write this for a long time and the ideas just kept pilling up in the back of my head. I know some things might not pe 100% accurate but the general ideas seem pretty useful.
Also I should give credit to Roxana, someone I know personally, which had some experiences that inspired quite a few ideas on this post. Her name will forever be remember in this post and I thank her again.
Comments
Post a Comment