The difference between then and now is a few things:
- 1. I actually, objectively, learn faster, I have more experience, more techniques at my disposal, and fast paths in my brain to do so.
- 2. The discomfort of not knowing something is much more pronounced relative to my usual competency.
When I was just starting out, the relative cost of #2 was the same for a number of topics.
Once you are an expert in one, working through feeling dumb all the time I imagine is much more frustrating.
What worked for me and the best advice I could possibly give is to identify the smartest programming writers and speakers that are doing what you want to do, read their books, watch their talks, and embody their viewpoints of code.
In the course of a few years of this you will gain a foundation whose benefits become more apparent over time.
Dealing with the perceived discomfort from #2, I'm not sure as I'm super-crabby and still young, but the most up-to-date and fresh experienced developers I've had the pleasure to work with embody a childlike curiosity.
#2 can be mitigated
#1 is a little more biological
I think #2 and related perceived tradeoffs dominate the learning equilibrium.
Link to Original Source
as is Linux, but a successful, socially relevant one.
People have the right to ask him to stop being abusive, but he has the right to do what he wants.
Take your EE background and rigor, and get a career in software. You'll have an edge over the hipsters and will find it easy to rise.
BS Biomedical Engineering from Georgia Tech.
MS Electrical and Computer Engineering from Georgia Tech
Some of the most talented programmers I work with are EE or physics guys.
You can redefine the functions w/ your own.
This is a road fraught with peril, likely because the people that implemented the original functions are the same ones that made crappy language choices that prevent new functions from being used effectively, so it's possible to both paper over issues, conveniently in the short term, and simultaneously creating more issues in the long-term.
1. Establish a clear goal and sub-goals.
2. Use the goals to determine the scope of your reading.
3. Allocate quite a bit of time in large chunks.
4. Identify key layers of abstraction.
5. Enumerate classes (functions, namespaces) of interest.
6. Systematically, read through each class superficially.
7. Pick 8 classes to focus on.
8. Do a deep dive.
9. List/sketch inputs and outputs in terms of function names, types referenced.
10. Look at relevant tests for usage as needed.
11. Check off each class once looked through.
12. Measure the complexity of a component by how many checks are required for full understanding.
13. Iterate until goals achieved.