I taught myself XML Schema a year before my employer at the time involuntarily forced me into programming. From XML Schema I learned a deep appreciation for language modeling, data structures, and relationships as trees.
When I was forced to program in JavaScript, my first language, the first thing I learned was to become very familiar with the DOM. The DOM is the backbone of everything frontend web and with that confidence you can do absolutely anything faster, both execution speed and development time, than most professionals with large frameworks. Understanding the document/page is a data structure of objects each with known relational paths to other nodes is a huge performance capability most people will never learn.
Then I really started to learn the actual language. Functions are everything. They are first class citizens which means they can be used and placed anywhere you can use and place a primitive, which is super expressive and portable. I also learned the advantages of the lexical scope model.
I learned early on that good software is explicit, portable, and highly predictable. If you have to guess at what’s happening when reading the code the code is poorly written. Code has flow control and the more immediately you, as a human, can read and trace that flow control the more durable your software is against defects and much faster to patch defects.
In my experience as a developer the biggest failure I see other developers make is that they never learn about automation. They expect some set of tools or memorized conventions to solve that for them. When the developer side of a software product is automated documentation is more available and up to date, performance is accounted for early on, regression analysis is baked in to warn you at the earliest, and so on.
The last major thing I learned as a developer was to measure things. Developers tend to guess at performance and tend to guess wrong by several orders of magnitude more than 80% of the time. Performance is either measured in duration (time to complete an operation) or frequency (operations per second). High performance is a force multiplier. Faster software features mean faster testing and faster analysis both manual and automated. Frequently waiting on software and page loading induces mental fatigue.
Honestly, not everyone can be good at software, but everyone can learn to write bad software. It’s the difference between administration and problem solving. To be good you need to have a passion for solving problems and improving things. It’s more than putting Lego blocks together. Anybody can snap some blocks together. To be good is more like determining what you need to do to take a car and cut the price in half while simultaneously making it faster than the competition.
If you do want to be good you need to innovate outside of work. If you are waiting for the job to tell you what to write you will be just as average as everyone else and lack the criticality to make more informed decisions about why current practices are crappy. That’s why measuring things is important.
Comments
As a self-taught developer here is how I did it.
I taught myself XML Schema a year before my employer at the time involuntarily forced me into programming. From XML Schema I learned a deep appreciation for language modeling, data structures, and relationships as trees.
When I was forced to program in JavaScript, my first language, the first thing I learned was to become very familiar with the DOM. The DOM is the backbone of everything frontend web and with that confidence you can do absolutely anything faster, both execution speed and development time, than most professionals with large frameworks. Understanding the document/page is a data structure of objects each with known relational paths to other nodes is a huge performance capability most people will never learn.
Then I really started to learn the actual language. Functions are everything. They are first class citizens which means they can be used and placed anywhere you can use and place a primitive, which is super expressive and portable. I also learned the advantages of the lexical scope model.
I learned early on that good software is explicit, portable, and highly predictable. If you have to guess at what’s happening when reading the code the code is poorly written. Code has flow control and the more immediately you, as a human, can read and trace that flow control the more durable your software is against defects and much faster to patch defects.
In my experience as a developer the biggest failure I see other developers make is that they never learn about automation. They expect some set of tools or memorized conventions to solve that for them. When the developer side of a software product is automated documentation is more available and up to date, performance is accounted for early on, regression analysis is baked in to warn you at the earliest, and so on.
The last major thing I learned as a developer was to measure things. Developers tend to guess at performance and tend to guess wrong by several orders of magnitude more than 80% of the time. Performance is either measured in duration (time to complete an operation) or frequency (operations per second). High performance is a force multiplier. Faster software features mean faster testing and faster analysis both manual and automated. Frequently waiting on software and page loading induces mental fatigue.
Honestly, not everyone can be good at software, but everyone can learn to write bad software. It’s the difference between administration and problem solving. To be good you need to have a passion for solving problems and improving things. It’s more than putting Lego blocks together. Anybody can snap some blocks together. To be good is more like determining what you need to do to take a car and cut the price in half while simultaneously making it faster than the competition.
If you do want to be good you need to innovate outside of work. If you are waiting for the job to tell you what to write you will be just as average as everyone else and lack the criticality to make more informed decisions about why current practices are crappy. That’s why measuring things is important.