July 1, 2015
Take in only that which makes you stronger.
This is advice that is good for everyone.
As it pertains to your abilities and career as a software engineer, however, there are certain things we can do or be aware of to ensure we are getting better as time passes.
There is a difference between deliberate practice and going through the motions.
This sounds obvious when stated, but if you show up to work and do the same things the same way for ten years, you won't be able to compete with people who show up with the mindset to improve themselves. There are a lot of people that believe that simply because they put the time in, they should be respected and put on a pedestal.
This isn't to say that experience over time is not valuable, in fact, it is invaluable! You can't put a price on seeing ten years of movement in this industry. We have a lack of truly senior people in our field. However, as I have mentioned earlier, showing up and putting CRUD screens together for ten years in a hardly-moving ecosystem can hardly qualify someone to be leading the next generation of developers.
To the main point, stagnation will always be our greatest enemy in this field. There are luckily many ways to combat this.
Seek people who are smarter than you, and latch onto them. At least find people as smart as you so you can develop your talents in tandem. Keep in mind, that because you're all human, you will have different opinions, and because you found people smarter than you, their opinions might have merit that isn't immediately apparent to you. Shut up and listen to them. Hear them all the way through, ask questions, and then try to pull out the parts you can really use.
Actively seek feedback from your peers. Whether it's for technical critique, or interpersonal advice, someone who doesn't have your tunnel vision can have important insights for you to act on. We typically don't waltz up to people and solicit them with negative feedback, which is why it's so important that we actively seek it. You don't want to be the stinky kid forever, if you ask sometime, they will likely tell you that you smell like hot ketchup. Don't be the stinky kid with no introspection.
It is absolutely critical that we keep an open mind, meaning that we are open to criticism, in any form. Whether it's an architect telling you why you shouldn't bother adding in a hook for some future feature, or a junior developer asking you why you needed to make some methods generic, there can be immense value in both if you are willing to pursue it.
With that in mind, know that there is a lot of noise and some people like to speak just to be heard. Only take from conversation that which makes you stronger, not that which someone told you is just the way to do things.
On that note, if you want to write blogs, or branch out into different technologies? DO IT. I have had people tell me that I shouldn't be polluting the internet with my opinions, or that focusing my efforts outside of the technology stack I use in my day job is a waste of time. Screw them. That will not make you stronger.
I know that this is a field where burnout and depression are very real threats. Never push yourself to those limits, and if you do? Yeah, take a break. Go take a walk in the woods, axe kick a copy machine, get some exercise. I find that I am always reinvigorated after bringing myself back to a good sleep and workout schedule. Throwing a conference in the mix puts the fire back in my belly too.
Past being open to ideas from other people and networking, the rest is quite easy to overcome. There is no emotional barrier to scanning news feeds for emerging technologies. There is no pro fighter boxing you out from buying the books you've heard about. There is nothing stopping you from tinkering with that app you've been meaning to work on.
You'll actually feel a lot better about yourself when you're being productive. You may also find that these things make you really good at your job. You may also find that being really good at your job not only wins reward from your employers, but also respect from your peers.
I don't know about you, but that last part sounds really good to me.
June 24, 2015
It is your duty to automate.
It is your duty to get rid of menial and repetitive manual tasks.
Why? Because they are an incredible waste of time, and you have the ability to remove them.
Think about it though, as engineers or whatever we call ourselves, we go on about how interruptions literally destroy our productivity. It goes up in smoke. It takes a fair bit of time for us to get back to wrestling the dragons in code. We have industry wide movements to reduce meetings to as few and short as possible. We outsource as much as we can that isn't coding to everyone else.
Even with all that, there are necessary evils in our line of work. We need to... wait for it... test our code to make sure it works before we send it off. Sometimes this involves testing HTTP calls, sometimes it's just verifying a database report pulls back what we expect, sometimes it's verifying the console app doesn't bomb out. I would say though, that the most time consuming testing is pixel pushing. When you need to walk through an entire user experience just to test that golden pot at the end of the rainbow.
The worst is when you have a stateful application, with a ton of setup that you as a developer need to run through every time you want to verify that some tiny change does what you expect in the bowels of your UI.
This especially stands out when you think of productivity lost in teams. If you have ten developers, and this setup takes maybe an hour to get through on average, and your developers have to do it even once a week, you're losing a lot of horsepower over the course of a year.
Barring 2 weeks for vacation
10 Developers * 1 Hr * 50 Wks = 500 Hrs
Okay, 500 hours of work lost across ten developers, or 50 hours per person, or 12.5 man weeks. However you put it, that is a massive waste of productive time.
Now think about all of the manual testing, the regression testing, and the bugs that sneak through anyways. You are retesting the same things over and over, with less and less rigour each time. You're not only wasting you and your teams time, you are doing the business you are working for an injustice because you could just as easily write some code to do it for you, and that code would test it better and for a longer time than you ever would. Write automaton for posterity! Your code will last a lot longer than you expect, and your tests will tell future generations what you intended.
If you're someone calling the shots, treating visitation of technical debt and automation as some waste of time is a big and consistent mistake. Believe me, leaving this debt unpaid will cost you and your team a lot of time and money, and you will not end up with the best developers. If you're a developer, and you are not following the boy scout rule, and automating the manual things you and your team do over and over and over again, you are wasting your time and theirs. You are not being professional.
I posit that a team that does not have test suites that will run through the vast majority of their system, either do not know better, or they are okay with being time vampires. This has exceptions, like every other generalization. Proof of concepts, marketing campaigns with an expiration date, and personal projects are a few of those exceptions. If you have a code base that is planned to be used for the foreseeable future, just write some automation.
If you're "moving too fast to write tests", you are probably doing it wrong. You're saying, I'm completely okay with throwing out all my hard work and starting over again. You're saying, I am willing to spend even more time later picking up humpty dumpty again. Have you ever heard about the stanford marshmallow study?
The Stanford marshmallow experiment was a series of studies on delayed gratification in the late 1960s and early 1970s led by psychologist Walter Mischel, then a professor at Stanford University. In these studies, a child was offered a choice between one small reward provided immediately or two small rewards if they waited for a short period, approximately 15 minutes, during which the tester left the room and then returned. (The reward was sometimes a marshmallow, but often a cookie or a pretzel.) In follow-up studies, the researchers found that children who were able to wait longer for the preferred rewards tended to have better life outcomes, as measured by SAT scores, educational attainment, body mass index (BMI), and other life measures.
Does any of the above sound like a decent metaphor to you?
I know I have been there, and sometimes I still take the marshmallow.
Are you sick of working on systems with tons of technical debt? Are you sick of "needing" to rewrite those systems from the ground up? Are you sick of manually testing all of your changes? Well start changing that now. Write automation, and save yourself the time and frustration so that you can work on the good stuff.
In the words of Shia La Boof, DO IT, YESTERDAY YOU SAID TOMORROW, SO JUST DO IT.
February 6, 2014
Hey everyone, haven't written in a while, but I write now with exciting news!
I have released my chess application. I am still working out a few kinks, but it has been a long time coming.
It doesn't work on IE8, but feel free to try it out on your mobile phone and let me know how you feel about it.
About a year and a half ago, I intended to have it released in a couple months, but life got in the way I suppose. Feel free to check it out, and let me know if there are any really glaring bugs. I know of a couple already that pertain to the validation of checkmate... Hopefully I will have those fixed before you find them though.
Don't become too attached to your record though, as this is only beta, I can not guaruntee the data will stick around, and I can also not guaruntee that it will stay at that URL for very long either.
Features coming soon:
- Email updates for turn notifications and challenges
- Chat client
- Common challenge creation
- Ability to view which pieces have been taken
- Ability to view game progressions in the history screen.
- Ability to request a draw
- Force forfeits after a particular time frame
Features coming eventually:
- Artifical intelligence (This is a big beast)
- Social network integration (Maybe sooner rather than later)
- Lessons in strategy (Tooltips while playing)
Other Work in the pipe:
Currently I have a few projects kicking around. One of which is a rental applications for tenants and landlords. This rental application is probably going to be what I bore into next... So these updates to the chess application are probably going to wait for a while, at least until I get this rental application out in the wild. Goal is in the next two months.Until next time everyone.... cheers!