I recently decide to read and understand the famous book of Hardy "Introduction to the Number Theory". It is a big book and my strategy is to read it slowly but with perseverance and patience. I think these two points are very important and maybe the key to achieve all our goals.
Nowadays, every thing go fast and we forget to take time to learn or to understand ideas, concepts, etc.
Each time you have some free minutes, do things that help you to achieve your goal. Small steps are very important.
To see what the Buddha saw, leading my brain to do the reassessment that causes freedom from suffering. I meditate daily and study related books like The Mind Illuminated.
I thought the same thing, but I’d have no idea what to do without work. If I didn’t have to save for kids college, I could retire now at 46. Other problem is 401k can’t be accessed until 60.
Retire for me just means enough FU money, but I’ll probably work till I drop dead.
Europe-based engineer here: Is a 401k completely unaccessible until 60?
I am currently resident of Switzerland, which has similar restrictions on the tax-free part of retirement savings, but allows earlier withdrawal for reasons such as
* purchasing a home (restriction: you have to live there yourself
There are actually a few ways to get money out of your 401k before the traditional retirement age. It involves rolling the funds over from your 401k into a traditional IRA, and then into a Roth IRA in what is sometimes known as a Roth ladder. Here's an article on it: http://rootofgood.com/roth-ira-conversion-ladder-early-retir...
The US has a first time homebuyer withdrawl carve-out (which I think is defined as someone who hasn’t bought a house in 8 years?). There are also hardship exemptions. Technically you can withdrawl for any reason but you pay taxes + a 10% penalty.
You can access your 401k before 60. You need to do a rollover into an IRA and then after 5 years the principle is accessible. This rollover is taxable but if you are retired your tax rate can be quite low, even 0% in some states depending on income. You should be in such no-income-tax states if you plan to retire early anyways.
TL;DR: I don't have long-term goals. I am setting short-term goals (at most a decade) and then re-evaluate my life purposes and begin again.
I don't really have goals longer that one decade from now. I don't really know what I want to have by the age of 80(im currently 29) so I am not concentrating there. I do know a few things I would like though and those are money and to still be working with interesting things that I love doing (programming, business running, hobbies, family, friends). So what I do is I set short-term goals that are making me work towards those life purposes. I am aware though that these purposes may change so I wouldn't like to work for two decades on making money and then suddenly realize that money was not what I really wanted.
So I set a goal 10 years ago and was stating that I wanted by the age of 30 to be a highly-paid (to fulfil my need for money) software engineer (to fulfill my need to do something that I love doing). I am very happy with my progress so far and I am still waiting for the time that I would make piece with myself and sit down to set the next goal which will also be short-term, something like "build a buisness by the age of 35 and marry your girl".
Alright, so this kind of values I am constantly trying to have regardless of the current goal I am in. Wealth, health, education, etc are on my schedule every day.
Reduce health care spending in the US by 50% without decreasing quality of life or life expectancy. Started a company that is trying to achieve those goals.
Near end of life procedures? A friend in health care told me 60% of one of our biggest hospital's costs go toward end of life (patient will die within weeks) treatments. Understandably, people request all the most expensive procedures because they don't want to let their loved ones go.
There are a wide variety of health care systems in other first world countries that are not single payer systems that don't have spending that is vastly higher than the countries that have single payer systems. For instance, Switzerland and the Netherlands both have mandatory private health insurance, similar to the way ACA was designed to work. Germany's system is based on a public option rather than being purely single payer.
I think instituting a single payer system in the US would be a good first step, but it is unlikely to completely solve our problems.
The main goal: Make more art. Specifically, the kind I call "art you have to plug in" -- kinetic art sculptures that include light, motion, and interactivity. I work towards achieving it by having my own company with a workshop full of the tools (3D printers, CNC mills, soldering stations, etc.) needed to make the art. The company uses those same tools to make products that solve problems for other companies. A portion of profits goes into funding the art projects. The technical skills needed to make the for-profit products are the same ones needed to make the art.
1. Grow my company to 20 or so employees.
2. Use $$$ from company to fund a large portion of other investments, interests. (my company isn't VC funded. Goal is for it to be a cash cow)
3. Level up personal brand enough to speak/travel a few times a quarter and see some cool places. Use that $$$ to pay for kids college.
A quite simple one: Build up enough of a nest egg so I can work solely on what I want to, when I want to. How? Build my company's revenues to a point where the industry multiple means I can sell and have the right amount, or.. just keep taking profit out until I have the right amount saved. It is as boring as that really.
Something I've become passionate about in the last couple of years is reliability in software and professionalism in software development.
I feel like we're at an inflection point where the cost of developing formal specifications is coming down enough for more teams to be using them in their practice. I'd like to continue that trend to allow more developers to use pure maths to solve their problems and use computers to verify (and maybe synthesize) their work.
I don't know what five years from now will look like but I'd like to either be working on or finishing a maths degree or starting a company to work on developing tools to work with formal specifications and proof automation and consulting with teams to help them write specifications for their critical components.
> How do you work towards achieving it?
I spend my free time working on problems in predicate calculus and writing specifications in TLA+ or Lean. I look for opportunities in my day-to-day work that would benefit from those skills. When it is time to think about my next position I will look for jobs that will help me get to that next level. Right now that means looking for opportunities to work on projects where reliability is highly desired and complexity is also quite high.
When I conduct 1-on-1's with my team I try to get people to think about their career. I like to encourage people to think strategically about their future. What do you want to be doing, in an ideal world, 2-3 years from now? What can we do now to set you up to be ready for that opportunity when it comes up?
This is something I think about from time to time as well, I haven't been able to see how to actually implement this in a real project. When I studied Computer Science, I had a particular interest in formal design, (studied Eiffel breifly) but haven't seen that aspect of it translate into my work.
I work in enterprise web application development, and the way projects are estimated, resourced and budgeted (in my experience) doesn't seem to offer any opportunities to try this. (Or I just haven't been smart enough to make a plan).
How would you go about creating a formal specification, to build something like a Facebook Messenger bot for an e-commerce store? Or something simpler like a Angular driven warehouse catalog application?
If you're new to it, focus on formally specifying parts and not the whole system. These sorts of specifications can become very complex very quickly. And if you're modeling them, the time to execute a model could take an inordinate amount of time.
For your two examples, rather than modeling how you communicate with Facebook for the bot, focus on how the bot gets data to and from your e-commerce store and how they stay synchronized or consistent. Your communication with Facebook's services may not even make it into your model. For the angular driven warehouse catalog application, same thing. You don't need to model angular and the UI. You need to model how the data gets to and from the UI and stays consistent with the warehouse catalog.
> If you're new to it, focus on formally specifying parts and not the whole system.
This.
Many detractors of formal methods will claim that software to too complex to specify formally and so it's no use.
I believe they are right. Software is quite complex. And that's why you should use tools to help you manage it. When you start building an event-sourced system architecture for your e-commerce system that scales up automatically and never goes offline during a deploy or single component failure... how will you know your design is correct? How will you measure your success?
(Yes, TDD encourages a sort-of informal "specification by example" and integration tests catch a lot of errors... but the kinds of things formal specifications have been proven to catch cannot be imagined by a mere mortal... despite the illusions of power programming has given us it is helpful to remember that illusions have no real power. You can write a specification to verify your design is free from race conditions given some context but you cannot anticipate all of the state-transitions that can lead to a race condition if all you're thinking about is the code)
This is why I think formal methods are useful and why you don't need to specify the whole system. Nobody is going to care if you have a formal proof that you can copy a file. What is going to be interesting is if you have a high-assurance specification that you can check which demonstrates that given any number of clients and command-dispatching processes eventually an order will be completed and no event will be recorded twice, out of order, or dropped (given that there are at least N dispatcher processes running and what-have-you). It is quite impressive if you can write a proof that if you write your program to maintain certain invariant properties then you do not need to have a lock in your program.
You can't prove those things with a bunch of boxes and lines.
My advice is to start small and try to work on a specification of a particular component or protocol that matters the most. I like to think about it in terms of risk. I'll ask myself questions like: what is the worst thing that could happen if we get this part wrong? or what part of this system do we have to absolutely ensure is right for the project to succeed?
If the answer the first question is not, "maybe someone will be annoyed or the business will find it annoying" then I increment the risk counter in the back of my mind. If the imaginary actuary assessing my project says that the cost of insuring the project against its risk is out-pacing what I can make from completing the project or potentially bringing harm to the business (or people) then I'll take a step back and consider ways to de-risk the project. There are many levers I can pull and I'm glad I have formal methods as I think that the cost of doing that work pays off in spades. Combined with other techniques and tools at our disposal it is much cheaper today to write highly reliable software than it has ever been.
Some brilliant advice there on breaking down long-term, often vague plans ("save the planet") to practical, actionable steps and expectations ("clean up your room").
I see your Mr Peterson (whom I love), and I raise you with the inimitable and sporadically brilliant Slavoj Zizek - whom I fucking hate so much that I love too.
Develop a framework for teaching people (and children) critical thinking, mental discipline and emotional control. The first part is relatively easy, the second, harder and the third, the hardest. How am I going to do that? First, I suppose I need to get to a point in my career and personal life where my finances are good enough that I don't have to decide where I spend my effort based on the income it'll bring me.
>First, I suppose I need to get to a point in my career and personal life where my finances are good enough that I don't have to decide where I spend my effort based on the income it'll bring me.
This. Waiting for the right moment to start working on your long term plan is, according to me, not a good idea. Instead of taking a giant step after some point of time, consider taking small steps on a regular basis.
I really like your idea, would you like to discuss how are you planning to approach this problem?
Well, recently I find myself approaching every problem of psychology with the starting point: "The human brain is a neural network, therefore..."
I'd like to somehow develop some new techniques based on this (as opposed to all the prevalent ones you find in self-help books). Right now I can't afford the time, but I should be able to make some headway next year. fingers crossed
I have two goals that I'm working on in parallel: advance on the technical or management track at the company I work for and build two side-businesses to the point where my after-tax income from them exceed my day job. For me "long-term" is 5 years (or less): I want to be quit of the software industry as soon as I can be.
For the first goal I split time at the company I work for between engineering work (design, implementation, mentoring junior engineers, etc.) and building relationships with product, marketing, and engineering leadership.
The two side-businesses are boring and use technology, but unlike my day job where I work in machine learning (up and down that "stack", from data engineering through research and model development) technology isn't the focus. I spend time in the evening after my kids have gone to bed developing or sourcing the supporting technology and working on product ideas and marketing and sales efforts.
78 comments
[ 2.9 ms ] story [ 131 ms ] threadThis is going to require more customers, and more help.
Like user "inp" said about his goal, it applies here too. Perseverance and patience.
One has to play the long game, for sure.
I do it by breaking things down into smaller and more manageable pieces. This helps prevent becoming overwhelmed.
Retire for me just means enough FU money, but I’ll probably work till I drop dead.
I am currently resident of Switzerland, which has similar restrictions on the tax-free part of retirement savings, but allows earlier withdrawal for reasons such as
* purchasing a home (restriction: you have to live there yourself
* leaving the country
Then, I'll be able to work on what I really want, without worrying about income.
I don't really have goals longer that one decade from now. I don't really know what I want to have by the age of 80(im currently 29) so I am not concentrating there. I do know a few things I would like though and those are money and to still be working with interesting things that I love doing (programming, business running, hobbies, family, friends). So what I do is I set short-term goals that are making me work towards those life purposes. I am aware though that these purposes may change so I wouldn't like to work for two decades on making money and then suddenly realize that money was not what I really wanted.
So I set a goal 10 years ago and was stating that I wanted by the age of 30 to be a highly-paid (to fulfil my need for money) software engineer (to fulfill my need to do something that I love doing). I am very happy with my progress so far and I am still waiting for the time that I would make piece with myself and sit down to set the next goal which will also be short-term, something like "build a buisness by the age of 35 and marry your girl".
I do know what I want to have: my health. Health is kind of relative at that age, but I'm working now to be the healthiest 80 year old I can be.
The answer seems to be universal single payer health care.
I think instituting a single payer system in the US would be a good first step, but it is unlikely to completely solve our problems.
Particularly, to end the American prison system and the policies of drug prohibition.
1. Grow my company to 20 or so employees. 2. Use $$$ from company to fund a large portion of other investments, interests. (my company isn't VC funded. Goal is for it to be a cash cow) 3. Level up personal brand enough to speak/travel a few times a quarter and see some cool places. Use that $$$ to pay for kids college.
I feel like we're at an inflection point where the cost of developing formal specifications is coming down enough for more teams to be using them in their practice. I'd like to continue that trend to allow more developers to use pure maths to solve their problems and use computers to verify (and maybe synthesize) their work.
I don't know what five years from now will look like but I'd like to either be working on or finishing a maths degree or starting a company to work on developing tools to work with formal specifications and proof automation and consulting with teams to help them write specifications for their critical components.
> How do you work towards achieving it?
I spend my free time working on problems in predicate calculus and writing specifications in TLA+ or Lean. I look for opportunities in my day-to-day work that would benefit from those skills. When it is time to think about my next position I will look for jobs that will help me get to that next level. Right now that means looking for opportunities to work on projects where reliability is highly desired and complexity is also quite high.
When I conduct 1-on-1's with my team I try to get people to think about their career. I like to encourage people to think strategically about their future. What do you want to be doing, in an ideal world, 2-3 years from now? What can we do now to set you up to be ready for that opportunity when it comes up?
For your two examples, rather than modeling how you communicate with Facebook for the bot, focus on how the bot gets data to and from your e-commerce store and how they stay synchronized or consistent. Your communication with Facebook's services may not even make it into your model. For the angular driven warehouse catalog application, same thing. You don't need to model angular and the UI. You need to model how the data gets to and from the UI and stays consistent with the warehouse catalog.
This.
Many detractors of formal methods will claim that software to too complex to specify formally and so it's no use.
I believe they are right. Software is quite complex. And that's why you should use tools to help you manage it. When you start building an event-sourced system architecture for your e-commerce system that scales up automatically and never goes offline during a deploy or single component failure... how will you know your design is correct? How will you measure your success?
(Yes, TDD encourages a sort-of informal "specification by example" and integration tests catch a lot of errors... but the kinds of things formal specifications have been proven to catch cannot be imagined by a mere mortal... despite the illusions of power programming has given us it is helpful to remember that illusions have no real power. You can write a specification to verify your design is free from race conditions given some context but you cannot anticipate all of the state-transitions that can lead to a race condition if all you're thinking about is the code)
This is why I think formal methods are useful and why you don't need to specify the whole system. Nobody is going to care if you have a formal proof that you can copy a file. What is going to be interesting is if you have a high-assurance specification that you can check which demonstrates that given any number of clients and command-dispatching processes eventually an order will be completed and no event will be recorded twice, out of order, or dropped (given that there are at least N dispatcher processes running and what-have-you). It is quite impressive if you can write a proof that if you write your program to maintain certain invariant properties then you do not need to have a lock in your program.
You can't prove those things with a bunch of boxes and lines.
My advice is to start small and try to work on a specification of a particular component or protocol that matters the most. I like to think about it in terms of risk. I'll ask myself questions like: what is the worst thing that could happen if we get this part wrong? or what part of this system do we have to absolutely ensure is right for the project to succeed?
If the answer the first question is not, "maybe someone will be annoyed or the business will find it annoying" then I increment the risk counter in the back of my mind. If the imaginary actuary assessing my project says that the cost of insuring the project against its risk is out-pacing what I can make from completing the project or potentially bringing harm to the business (or people) then I'll take a step back and consider ways to de-risk the project. There are many levers I can pull and I'm glad I have formal methods as I think that the cost of doing that work pays off in spades. Combined with other techniques and tools at our disposal it is much cheaper today to write highly reliable software than it has ever been.
https://www.youtube.com/watch?v=_vAat1HQU0M
Some brilliant advice there on breaking down long-term, often vague plans ("save the planet") to practical, actionable steps and expectations ("clean up your room").
Happiness is an unethical "cut-ay-gory":
https://www.youtube.com/watch?v=U88jj6PSD7w
(For those you aren't aware of his tick, don't watch, just listen)
This. Waiting for the right moment to start working on your long term plan is, according to me, not a good idea. Instead of taking a giant step after some point of time, consider taking small steps on a regular basis.
I really like your idea, would you like to discuss how are you planning to approach this problem?
I'd like to somehow develop some new techniques based on this (as opposed to all the prevalent ones you find in self-help books). Right now I can't afford the time, but I should be able to make some headway next year. fingers crossed
For the first goal I split time at the company I work for between engineering work (design, implementation, mentoring junior engineers, etc.) and building relationships with product, marketing, and engineering leadership.
The two side-businesses are boring and use technology, but unlike my day job where I work in machine learning (up and down that "stack", from data engineering through research and model development) technology isn't the focus. I spend time in the evening after my kids have gone to bed developing or sourcing the supporting technology and working on product ideas and marketing and sales efforts.