6 ms·

Start building the things that you want to build, and you'll learn what you need to along the way. This is the strategy that has brought me the most joy and, no

Start building the things that you want to build, and you'll learn what you need to along the way. This is the strategy that has brought me the most joy and, not coincidentally, it has also been the most effective by far.

bosie 6y ago
How do you make sure you aren't hitting a local optimum of sorts where you implement a solution that has terrible side effects you simply aren't aware of (yet)? This seems to happen when you 'learn along the way' rather than start with a deeper learning upfront?
- deleted 6y ago
  [deleted]
- orisho 6y ago
  By deliberately selecting your objectives and evaluating possible solutions based on those objectives. If the objectives are unclear when you start (e.g. your objective is achieve a certain level of perfomance but you don't know enough to know what you can adjust, or how you can measure, or what delivers the most gain for least effort), I just get started and revisit it once I have something basic going. Often, a basic, naive solution will give you the understanding and domain knowledge you need to be able to read what others have said about the same problem. It also allows you to more easily dive into the solution as implemented by popular open source projects. Even if they don't write about it, you can often learn a lot from the code -- even more if the rationale is written in comments in the code. For example, let's say you're contemplating how to implement an audit log for your product. You've never done this before, but you're experienced enough to know that you might hit unexpected hurdles (such as features that are difficult to implement) well into development, or maybe after deployment. Something you might do is research commercial open source products which have an audit log, and read their code to understand how they did it and perhaps why. Another way you can figure out the rationale is by looking at their full set of features and asking yourself how might each feature be implemented in an alternative implementation. If alternative implementations don't work well with this feature, this could provide an answer for why they chose this implementation over the other. And then finally, you can ask yourself if you need these features, which brings you answers to the original question of what are your objectives. Or the short version: there are indirect ways to learn from the experience of others. Looking at a battle-tested implementation of a feature you want to add is one -- and it's perhaps even better (= more enlightening) than reading some blog posts you might find.
- tdsamardzhiev 6y ago
  Anything you can come up with is a local optimum if you zoom out enough. If it gets the job done, no need to worry about that. If it doesn't, refactoring it will be a good learning experience.
  - deleted 6y ago
    [deleted]
  - ProZsolt 6y ago
    Yes, when you're leaning something you have to constantly refactor. It's part of the fun. You don't have hard deadlines so you don't have to get it right at the first time.
- xgb84j 6y ago
  I do that partially by focusing explicitly on a single objective like performance or test coverage. In reality you need to compromise, but by keeping the scope of learning projects artificially small you learn a lot about that one aspect and the trade offs involved. For example when I wanted to learn more about testing for front end applications in Angular, I wrote all types of different tests for a small sample project. By doing that and reflecting on how I could incorporate all those tests at work, I learned a lot about structuring my code to be more testable, when and how to use mocks, Angulars built-in testing utilities and much more. By going very narrow it's easier to go deep. You won't learn about all the side effects and interactions with decisions in other areas, but at least you know more options and can try to find a better optimum.
ipnon 6y ago
Yes, by always working on the most interesting problem available to you, you have an endless fountain of your most valuable resource: motivation. A sufficiently motivated problem is sure to be solved because there is no incentive to quit. All of the greatest insights come from sufficiently motivated problems. There is no great science without a fire. "I have no special talents. I am only passionately curious."
Ologn 6y ago
I think this is a big part of it. At work, I am coding to one platform. For my personal projects - I set up the Linux server, I set up the MySQL/MariaDB instance, I design the database schema which follows first normal form, second normal form. I design the REST API in Python, then I get to my normal job of coding an app for one platform. Plus I do the graphics, which normally the design group does. I also do the advertisement on Google Ads etc., I pay the bills and do the accounting and so on. So it goes beyond even tech skills. Thomas Huxley said a good liberal education is to know something about everything and everything about something. I am not an expert in creating ads on Google, Twitter etc., but I have done it and know something of it. Same with sizing or dropping graphical icons. Or designing a database schema. Or figuring out my side project cash flow, profit and loss, having my accountant help me set up an S corporation. This is all the knowing a little something about everything. In my day job I primarily use one programming language to target one platform. In this subject I go deep and really try to learn as much as I can. This is what my main focus is on, learning the language well, and learning the platform well. I should also point out, the smaller a company is, the more hats you will wear. I worked at a small company where I wore not only a programmer hat but a devops hat. I set up Google Cloud, Firebase Firestone, Apache web server, and wrote and modified Python scripts. At a larger company (where I am now), 99% of the time I do none of these things (actually they like I have these skills and can interact with our devops team). It doesn't take long for specialization to kick in either, by the time of the second tech hire you're already dividing up work. It is important to know your main focus well on job interviews though.

bosie 6y ago

How do you make sure you aren't hitting a local optimum of sorts where you implement a solution that has terrible side effects you simply aren't aware of (yet)? This seems to happen when you 'learn along the way' rather than start with a deeper learning upfront?

deleted 6y ago
[deleted]
orisho 6y ago
By deliberately selecting your objectives and evaluating possible solutions based on those objectives. If the objectives are unclear when you start (e.g. your objective is achieve a certain level of perfomance but you don't know enough to know what you can adjust, or how you can measure, or what delivers the most gain for least effort), I just get started and revisit it once I have something basic going. Often, a basic, naive solution will give you the understanding and domain knowledge you need to be able to read what others have said about the same problem. It also allows you to more easily dive into the solution as implemented by popular open source projects. Even if they don't write about it, you can often learn a lot from the code -- even more if the rationale is written in comments in the code. For example, let's say you're contemplating how to implement an audit log for your product. You've never done this before, but you're experienced enough to know that you might hit unexpected hurdles (such as features that are difficult to implement) well into development, or maybe after deployment. Something you might do is research commercial open source products which have an audit log, and read their code to understand how they did it and perhaps why. Another way you can figure out the rationale is by looking at their full set of features and asking yourself how might each feature be implemented in an alternative implementation. If alternative implementations don't work well with this feature, this could provide an answer for why they chose this implementation over the other. And then finally, you can ask yourself if you need these features, which brings you answers to the original question of what are your objectives. Or the short version: there are indirect ways to learn from the experience of others. Looking at a battle-tested implementation of a feature you want to add is one -- and it's perhaps even better (= more enlightening) than reading some blog posts you might find.
tdsamardzhiev 6y ago
Anything you can come up with is a local optimum if you zoom out enough. If it gets the job done, no need to worry about that. If it doesn't, refactoring it will be a good learning experience.
- deleted 6y ago
  [deleted]
- ProZsolt 6y ago
  Yes, when you're leaning something you have to constantly refactor. It's part of the fun. You don't have hard deadlines so you don't have to get it right at the first time.
xgb84j 6y ago
I do that partially by focusing explicitly on a single objective like performance or test coverage. In reality you need to compromise, but by keeping the scope of learning projects artificially small you learn a lot about that one aspect and the trade offs involved. For example when I wanted to learn more about testing for front end applications in Angular, I wrote all types of different tests for a small sample project. By doing that and reflecting on how I could incorporate all those tests at work, I learned a lot about structuring my code to be more testable, when and how to use mocks, Angulars built-in testing utilities and much more. By going very narrow it's easier to go deep. You won't learn about all the side effects and interactions with decisions in other areas, but at least you know more options and can try to find a better optimum.

ipnon 6y ago

Yes, by always working on the most interesting problem available to you, you have an endless fountain of your most valuable resource: motivation. A sufficiently motivated problem is sure to be solved because there is no incentive to quit. All of the greatest insights come from sufficiently motivated problems. There is no great science without a fire. "I have no special talents. I am only passionately curious."

Ologn 6y ago

I think this is a big part of it. At work, I am coding to one platform. For my personal projects - I set up the Linux server, I set up the MySQL/MariaDB instance, I design the database schema which follows first normal form, second normal form. I design the REST API in Python, then I get to my normal job of coding an app for one platform. Plus I do the graphics, which normally the design group does. I also do the advertisement on Google Ads etc., I pay the bills and do the accounting and so on. So it goes beyond even tech skills. Thomas Huxley said a good liberal education is to know something about everything and everything about something. I am not an expert in creating ads on Google, Twitter etc., but I have done it and know something of it. Same with sizing or dropping graphical icons. Or designing a database schema. Or figuring out my side project cash flow, profit and loss, having my accountant help me set up an S corporation. This is all the knowing a little something about everything. In my day job I primarily use one programming language to target one platform. In this subject I go deep and really try to learn as much as I can. This is what my main focus is on, learning the language well, and learning the platform well. I should also point out, the smaller a company is, the more hats you will wear. I worked at a small company where I wore not only a programmer hat but a devops hat. I set up Google Cloud, Firebase Firestone, Apache web server, and wrote and modified Python scripts. At a larger company (where I am now), 99% of the time I do none of these things (actually they like I have these skills and can interact with our devops team). It doesn't take long for specialization to kick in either, by the time of the second tech hire you're already dividing up work. It is important to know your main focus well on job interviews though.