I have been engineering for a few years now and I feel overwhelmed at times by trying to accomplish things while still being informed about the things that I am working on.
I am interested in how people balance the learning vs producing part of their careers. After about 5 years do people end up gravitating towards one niche area and become experts in that area? I find that I am faced with new challenges weekly in areas that are not very similar. One day I could be writing a database application using SQL server and C# .net and the next day I could be writing data acquisition and control applications in C on a ARM microcontroller.
So for example, when getting into database programming in C# I find good books, blogs and resource sites and then start reading through all the information I can find. Fortunately these days you can avoid reinventing the wheel and making common mistakes by learning from the massive amounts of knowledge out there. That is also a downside because each topic (SQL and C#, embedded C programming etc) has an almost limitless supply of knowledge to cover. So I ended up after many hours of study using MVVM WPF with Entity Framework through a generic repository pattern with unit of work and specification.
The first version I wrote was junk because I did not know enough, the last version was good but took a very long time since it took so long to learn the concepts and not just "this is what it is" but "this is why and how it works"
I find I spend at least twice as many hours learning (much on my own time) than I do actually writing code, drafting a PCB or assembly in SolidWorks. Is this too much?
My own personal projects rarely get off the ground since once I have an idea and then start to learn about the concepts I will need to know I end up spending weeks just reading. I wonder if I should limit the learning to something like 10 hours to start with and then just build, even if it is not entirely the right way or most efficient way?
The second part of the question is how to you keep track of all the knowledge and tools. I have hundreds of pages of reference material organized in OneNote, and it has provided to be useful from the handy search functionality built in. If I found a particularly useful state machine implementation and learned the caveats of it I can quickly review everything I have learned to avoid making the same mistakes.
A single specific example would be for MPLAB X. By default the project does not generate the startup code file and during debugging skips over the startup code to start from main(). There is a way in the options to change this behavior so it will generate the startup code and will pause execution right at the start of debugging so you can break in the startup code. I remember this much, but as far as the exact option setting in the exact dialog I cannot recall off the top of my head. I can find it the way I have stuff organized now.
Does anyone else do this? Is it over-documenting?
So really tldr; what is the right balance between learning and producing? What is the best way to document all the information and findings so you can re-use it in the future?
As a final note, do you realize how much information there is out there? Right now just looking at drafting in Inventor and it is insane. There is the different design methodologies (top-down, bottom up, master file, skeletal modeling) then all of the specific ways of achieving stuff (try make a screw or acme threaded rod from scratch, or a belt). Also specific techniques like projecting geometry. I have about 300 hours of books, Lynda courses, webinars and tutorials lined up that look really necessary to take before trying to draft anything seriously as a professional in this software (300 hours is not enough from scratch but I do have relevant experience with other software)
Anyone have any feedback or ideas about this?
I am interested in how people balance the learning vs producing part of their careers. After about 5 years do people end up gravitating towards one niche area and become experts in that area? I find that I am faced with new challenges weekly in areas that are not very similar. One day I could be writing a database application using SQL server and C# .net and the next day I could be writing data acquisition and control applications in C on a ARM microcontroller.
So for example, when getting into database programming in C# I find good books, blogs and resource sites and then start reading through all the information I can find. Fortunately these days you can avoid reinventing the wheel and making common mistakes by learning from the massive amounts of knowledge out there. That is also a downside because each topic (SQL and C#, embedded C programming etc) has an almost limitless supply of knowledge to cover. So I ended up after many hours of study using MVVM WPF with Entity Framework through a generic repository pattern with unit of work and specification.
The first version I wrote was junk because I did not know enough, the last version was good but took a very long time since it took so long to learn the concepts and not just "this is what it is" but "this is why and how it works"
I find I spend at least twice as many hours learning (much on my own time) than I do actually writing code, drafting a PCB or assembly in SolidWorks. Is this too much?
My own personal projects rarely get off the ground since once I have an idea and then start to learn about the concepts I will need to know I end up spending weeks just reading. I wonder if I should limit the learning to something like 10 hours to start with and then just build, even if it is not entirely the right way or most efficient way?
The second part of the question is how to you keep track of all the knowledge and tools. I have hundreds of pages of reference material organized in OneNote, and it has provided to be useful from the handy search functionality built in. If I found a particularly useful state machine implementation and learned the caveats of it I can quickly review everything I have learned to avoid making the same mistakes.
A single specific example would be for MPLAB X. By default the project does not generate the startup code file and during debugging skips over the startup code to start from main(). There is a way in the options to change this behavior so it will generate the startup code and will pause execution right at the start of debugging so you can break in the startup code. I remember this much, but as far as the exact option setting in the exact dialog I cannot recall off the top of my head. I can find it the way I have stuff organized now.
Does anyone else do this? Is it over-documenting?
So really tldr; what is the right balance between learning and producing? What is the best way to document all the information and findings so you can re-use it in the future?
As a final note, do you realize how much information there is out there? Right now just looking at drafting in Inventor and it is insane. There is the different design methodologies (top-down, bottom up, master file, skeletal modeling) then all of the specific ways of achieving stuff (try make a screw or acme threaded rod from scratch, or a belt). Also specific techniques like projecting geometry. I have about 300 hours of books, Lynda courses, webinars and tutorials lined up that look really necessary to take before trying to draft anything seriously as a professional in this software (300 hours is not enough from scratch but I do have relevant experience with other software)
Anyone have any feedback or ideas about this?
