Since I graduated from university (major in English literature), my work has always been in the orbit of software and IT work: first, as a technical writer, then as a computer technician, and finally as a security technician.
Over the years I tinkered with Linux and spent (too) many hours picking up tips and tricks about how to get my computer to do my bidding, rather than contort my daily use around its default settings. This involved writing lots of scripts in Python.
However, my journey into software development (a work in progress) started in earnest in June 2016. After talking about work with my housemate, a business analyst and his brother, a software developer, I initially leaned towards DevOps, and accordingly researched DevOps tools and theory. I tinkered with AWS, set up LAMP stacks, got the hang of Vagrant, and taught myself elementary PHP. I sent cover letters and telephoned an array of recruiters for guidance on how to work my way into a starting position in the industry.
After a few months it became clear to me that there is in practice no direct path for me into a DevOps role: even the most junior DevOps role requires professional experience in systems administrations or in a commercial software development environment, neither of which I possessed.
In October 2016, I reviewed my goals and decided to focus my efforts on software development instead. After years of scripting in Python on Linux, I was already familiar with many of the fundamentals of programming, and although I did not underestimate the enormity of this task, I was confident it could be done. I considered primarily Python, Ruby, and Javascript, and eventually settled on Ruby on the strength of the work opportunities and the community in Melbourne. I had always loved open source and Ruby code appeals to my aesthetic sensibilities.
I went to America in November and upon my return, I started the next chapter in my journey into software development. I completed study modules on Rails, AWS, HTML/CSS, and JavaScript. On the Ruby side I completed the course at Code Academy, worked through 'Learn Ruby the Hard Way' by Zed Shaw and 'Toy Robot' by Ryan Bigg, and at the time of writing am currently working through the puzzles on Advent of Code.
I also make nerdy t-shirts:
My job is to get a job, and it is to this end that all my efforts in studying programming, writing code, blogging, planning, and networking are directed. It is tricky to strike a balance, because what I really want to do is code and study to code better, rather than promote myself. In order to achieve this balance, I manage my time carefully, work as productively as possible, and prioritise my activities rationally and with discipline. From day to day, I can give a full account of where I was, what I did, what I got done, how much time I spent on each task, and where I fell short of my goals. The system I have devised for myself is the fruit of many years of research, trial and error, and it comprises the following:
Mindmaps and charts for setting goals:
Storyboarding and progress charts for reviewing my progress:
Kanban for managing tasks and prioritisation:
A daily schedule:
Pomodoro method for maximising productivity throughout the day
And blogging, of course:
By means of these tools and methods, I generally complete 12-16 pomodoros per day of productive labour across the following categories:
In addition to these, I cook all my own food and keep house.
I attend all of the social and networking events related to Ruby and Rails, and make a point of speaking to new people. Although I prefer to listen to others' stories, I understand the importance of putting myself out there and share my story; I routinely ask for criticism and make a point of highlighting the shortcomings in my approach that I can detect, in the hope of eliciting further constructive criticism.
From 06:00 until 18:00, Monday to Friday, it is a race against the clock to see how many blocks of work I can complete, and within each work-block, that same race is run at a sprint to complete a specific task or solve a problem. I can say without a doubt that I have never worked so productively and efficiently, although I never give up the pursuit of working smarter and doing things a little better each day.
Over the years I tinkered with Linux and spent (too) many hours picking up tips and tricks about how to get my computer to do my bidding, rather than contort my daily use around its default settings. This involved writing lots of scripts in Python.
However, my journey into software development (a work in progress) started in earnest in June 2016. After talking about work with my housemate, a business analyst and his brother, a software developer, I initially leaned towards DevOps, and accordingly researched DevOps tools and theory. I tinkered with AWS, set up LAMP stacks, got the hang of Vagrant, and taught myself elementary PHP. I sent cover letters and telephoned an array of recruiters for guidance on how to work my way into a starting position in the industry.
After a few months it became clear to me that there is in practice no direct path for me into a DevOps role: even the most junior DevOps role requires professional experience in systems administrations or in a commercial software development environment, neither of which I possessed.
In October 2016, I reviewed my goals and decided to focus my efforts on software development instead. After years of scripting in Python on Linux, I was already familiar with many of the fundamentals of programming, and although I did not underestimate the enormity of this task, I was confident it could be done. I considered primarily Python, Ruby, and Javascript, and eventually settled on Ruby on the strength of the work opportunities and the community in Melbourne. I had always loved open source and Ruby code appeals to my aesthetic sensibilities.
I went to America in November and upon my return, I started the next chapter in my journey into software development. I completed study modules on Rails, AWS, HTML/CSS, and JavaScript. On the Ruby side I completed the course at Code Academy, worked through 'Learn Ruby the Hard Way' by Zed Shaw and 'Toy Robot' by Ryan Bigg, and at the time of writing am currently working through the puzzles on Advent of Code.
I also make nerdy t-shirts:
Sales and Marketing
I treat this career change as a full-time job... in marketing.My job is to get a job, and it is to this end that all my efforts in studying programming, writing code, blogging, planning, and networking are directed. It is tricky to strike a balance, because what I really want to do is code and study to code better, rather than promote myself. In order to achieve this balance, I manage my time carefully, work as productively as possible, and prioritise my activities rationally and with discipline. From day to day, I can give a full account of where I was, what I did, what I got done, how much time I spent on each task, and where I fell short of my goals. The system I have devised for myself is the fruit of many years of research, trial and error, and it comprises the following:
Mindmaps and charts for setting goals:
Storyboarding and progress charts for reviewing my progress:
Kanban for managing tasks and prioritisation:
A daily schedule:
Pomodoro method for maximising productivity throughout the day
And blogging, of course:
By means of these tools and methods, I generally complete 12-16 pomodoros per day of productive labour across the following categories:
- Coding
- Studying coding
- Blogging and planning
- Job-seeking
- Translation from English to Lithuanian
- Studying Lithuanian grammar
- Daily exercise
- Daily strength training
- Creative writing
In addition to these, I cook all my own food and keep house.
I attend all of the social and networking events related to Ruby and Rails, and make a point of speaking to new people. Although I prefer to listen to others' stories, I understand the importance of putting myself out there and share my story; I routinely ask for criticism and make a point of highlighting the shortcomings in my approach that I can detect, in the hope of eliciting further constructive criticism.
From 06:00 until 18:00, Monday to Friday, it is a race against the clock to see how many blocks of work I can complete, and within each work-block, that same race is run at a sprint to complete a specific task or solve a problem. I can say without a doubt that I have never worked so productively and efficiently, although I never give up the pursuit of working smarter and doing things a little better each day.
