My tech news years resolutions
The start of a new year provides the perfect, if a little arbitrary, opportunity to reflect on the mistakes and milestones made over the last 12 months. I made plenty of both last year, which leads me to the following tech news years resolutions.
1. I'm done with stats
Last year saw the publishing of my first book, and the tail end of my freelance blogging efforts. While both projects made a meaningful contribution to my life in their own subtle ways, I can't help but feel that I spent an incredible amount of time and effort trying to earn that next $10. When I think about the scheming and plotting and analysing that went into making enough money for a bus fare, I can't help but come to the conclusion that I was prospecting for fools gold.
So I'm done watching graphs. This year I will only post content that interests me, and not create something for the sake of a few page views.
2. I will develop services first, applications second
I spent most of last year in charge of developing an ill-defined project which, through a combination of chance, some managerial faith, the enthusiasm of a few few employees and my own determination, has become an integral part of the departments workflow.
What I learned through this process is that enterprise applications should not be thought of as applications at all. They are almost always services or platforms. A monolithic application is initially functionally equivalent to service with a single user interface, but the second someone starts querying your database directly in order to generate a report or prototype a cool idea they had, you go from being the hero developer of that kick ass app to that developer of yet another information silo.
So this year I will stop seeing classes and function as the entry point to my own data, and will instead create services on which I then build user interfaces.
3. I will stop assuming that I can deploy to a bigger server
It's easy to assume that performance issues can be solved by running your code on more powerful hardware. Last year I placed a lot of emphasis on writing multi-threaded code, which would then, in theory, scale nicely as the code was moved onto a server with more cpu cores.
What I have realised is that it is far easier to get access to multiple low end servers (or VMs) than it is to get access to one high performance server. Which actually takes me back to my second resolution. If my application was a collection of networked services I could have solved my performance issues by spinning up new VMs instead of hitting the boss up for a shiny new server.
So this year I code under the assumption that my project will be running on a collection of commodity hardware.
4. I will make time for training
When I am solving a problem I tend to have tunnel vision. To get that problem fixed I will ignore everything from the moment I wake up until that point at the end of the day when my brain turns to mush and I find myself staring at the screen fixing spelling errors in the code comments (the developers out there will know what I am talking about).
This year I will force myself to spend even just half an hour a day reading a book written by someone who has dealt with the problems I am dealing with. I might need to get an egg timer, I might need to sit in another room, or I might need to leave the house and sit at a cafe. Whatever it takes, this year I make time for training.
1. I'm done with stats
Last year saw the publishing of my first book, and the tail end of my freelance blogging efforts. While both projects made a meaningful contribution to my life in their own subtle ways, I can't help but feel that I spent an incredible amount of time and effort trying to earn that next $10. When I think about the scheming and plotting and analysing that went into making enough money for a bus fare, I can't help but come to the conclusion that I was prospecting for fools gold.
So I'm done watching graphs. This year I will only post content that interests me, and not create something for the sake of a few page views.
2. I will develop services first, applications second
I spent most of last year in charge of developing an ill-defined project which, through a combination of chance, some managerial faith, the enthusiasm of a few few employees and my own determination, has become an integral part of the departments workflow.
What I learned through this process is that enterprise applications should not be thought of as applications at all. They are almost always services or platforms. A monolithic application is initially functionally equivalent to service with a single user interface, but the second someone starts querying your database directly in order to generate a report or prototype a cool idea they had, you go from being the hero developer of that kick ass app to that developer of yet another information silo.
So this year I will stop seeing classes and function as the entry point to my own data, and will instead create services on which I then build user interfaces.
3. I will stop assuming that I can deploy to a bigger server
It's easy to assume that performance issues can be solved by running your code on more powerful hardware. Last year I placed a lot of emphasis on writing multi-threaded code, which would then, in theory, scale nicely as the code was moved onto a server with more cpu cores.
What I have realised is that it is far easier to get access to multiple low end servers (or VMs) than it is to get access to one high performance server. Which actually takes me back to my second resolution. If my application was a collection of networked services I could have solved my performance issues by spinning up new VMs instead of hitting the boss up for a shiny new server.
So this year I code under the assumption that my project will be running on a collection of commodity hardware.
4. I will make time for training
When I am solving a problem I tend to have tunnel vision. To get that problem fixed I will ignore everything from the moment I wake up until that point at the end of the day when my brain turns to mush and I find myself staring at the screen fixing spelling errors in the code comments (the developers out there will know what I am talking about).
This year I will force myself to spend even just half an hour a day reading a book written by someone who has dealt with the problems I am dealing with. I might need to get an egg timer, I might need to sit in another room, or I might need to leave the house and sit at a cafe. Whatever it takes, this year I make time for training.
Comments