Archive for 'Rant'
It has been a little while since I posted a new episode, so when inspiration struck me while waiting in the car, I didn’t pass up the opportunity to record Episode 38. I used my phone as a voice recorder and shared a kind of stream-of-consciousness rant. Some things had really piled up on me recently, not the least of which was my disgust with much of the development community at large. Major targets of my focus include judgement of new developers, judgement of people by their technology of choice, my dislike of “Why I’m Leaving X” posts, and how being yourself doesn’t mean that you need to be a douche when interacting with others.
Links Mentioned in this Show:
21 Management Things I Learned at Imgur
You can also subscribe to the podcast at any of these places:
In addition, my podcast is available on DoubleTwist and the Windows Marketplace.
Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.
An article was posted over at Mashable titled 8 Signs It’s Time to Leave Your Job. I can see their perpective on all of their points, but to me their 8th point was the main point.
You are no longer passionate about your work and dread going to the office each day.
That is my number one criteria for looking for new employment. Do I dread going into work? Am I excited about the kinds of things that I get to do at my job? Not every day is a mountaintop, but if you have a prolonged period of dreading work, then you should consider moving on. All of the other points roll into that one. They talk about politics and high profile work, etc. Different strokes for different folks and some people aren’t affected by the same things that affect others. It all comes down to whether or not you die a little inside when the alarm goes off in the morning.
Assuming that you’re getting paid basically what you can make elsewhere (give or take a few percent) and that your benefits are fine, the only other consideration in my mind is whether or not your skills are being allowed to grow, or whether they are stagnating.
For example, if you are a .Net developer and your workplace is still working on the .Net Framework 2.0 and you are only using Web Forms and you are on SQL Server 2000 with no chance of an upgrade, you should think about going even if you are happy. Your alternative is to get very involved in “new technologies” in your spare time so that you don’t become easily expendable.
The days of working somewhere for 40 years and retiring with a gold watch and a pension are basically extinct. If you allow a job to manage your career for you, you will find a time where it is 2013 and you are looking for work and you have been doing FoxPro 6 or Classic ASP for 15 years and now you can’t find a job that will pay you anywhere near what you need to support yourself and possibly a family.
So it is all summed up very simply as to whether or not you like going to work every day. If you love the place and it is feeding your career, then you already know that you shouldn’t be looking anywhere else.
If you love the place and it is strangling your career, consider whether or not you have the time or inclination to put in the work “off hours” in a very big way to gain the requisite experience in “new technologies” that you may or may not use professionally. If you don’t have that time or inclination, look to move on, even if you love your job.
If you don’t love waking up in the morning to go to work, get out. Life is too short for almost anything else to matter.
Rob Conery tweeted about a blog post that “Kakubei” made back in May of 2012. You can read about it over here.
I find it interesting that the author starts off the post making a comparison between himself and his brother. That his brother’s academic success and his own academic failings (and subsequent self-taught programming skills) are at odds and that the industry would view one of them as a “real programmer” and the other one as not a “real programmer”.
As I often like to point out, every programmer is a self taught programmer. You may get the fundamentals at college and learn some things that can make you more efficient or a better designer of computer systems, but with the pace that technology is changing, you have to constantly learn to keep up.
That being said, Kakubei’s main complaint is that Rails is hard to learn. He compares the canonical “15 minute blog” demos to what it takes to do “real world” Rails development and he comes up with a big differential.
What I find funny is that he seems to have come from a PHP background. That means that he had to know the PHP language, possibly a PHP framework (like Cake), HTML, CSS, JS, probably MySql, etc. I say that to say this, he had to know a lot to work and he wasn’t coming to Rails from zero.
I think this all boils down to something else, though. What does it take to be productive or at least “mildly useful” in a language/framework?
To me, I was able to follow a simple Rails tutorial and starting using Rails almost immediately. Know what I didn’t need? RVM. Just starting out, I just used one version of Ruby and Rails. As for Gems, in order to do my tutorial, I had to say “gem install rails”, so I already had an idea how it worked. After that, you can pretty much avoid using it if you don’t mind rewriting code that is already a “solved problem”.
What about HomeBrew? Don’t need it. Active Record? All you need to know to actually make stuff happen is in the “15 minute” video. Same with the MVC pattern. I didn’t know anything about making MVC websites and I was up and moving with minimal instruction from the video. Rake? Didn’t need anything special there, either, because I hadn’t created a very complicated system yet. Capistrano? I need an automated deployment on day one?
My point is that every rabbit hole is very deep. .Net? WebForms or ASP.Net MVC? HTML, CSS, JS/jQuery. Dependency Injection with AutoFac/AutoMapper/Ninject. ORMs like Entity Framework, NHibernate, etc. Don’t forget the language (C# or VB.Net or F# or whatever). How about Nuget for package management? Don’t forget source control, like TFS or Git. What about knowing testing like NUnit, xUnit, MSTest? Deploying with MSBuild and MSDeploy or one of the bajillion open source tools?
I could follow the same path to describe getting started in web development with Node.js or Python or whatever you could think of. It is silly to think that you can go from 0 to Amazing in 15 short minutes. That pattern doesn’t work.
What you have to know is how to learn. You have to know how to Just-In-Time the information so that you can be productive from the jump off. Yes, that means that you’ll always be learning, but if that concept doesn’t excite you, then you are probably in the wrong field.
I believe that that sort of complaining (“The development stack is too deep/rich”) shows a certain level of professional immaturity.
I realize that after Rob tweeted, Kakubei added an update after people started commenting, saying:
“I’ve been using Rails for more than a year and I still use it. In fact, I’m in the process or rewriting our main application’s API in Padrino with ActiveRecord, Thinking Sphinx and deploying to Heroku and it has been a primarily positive experience despite some teething issues. The admin for our database I’ve written in Rails 3.2 and there is a lot to like there. The idea was to write another post after this one titled “Why I love Rails” but I never got around to it. Even though this post is a rant, I still feel that way about Rails, so keep those comments coming, but don’t feel you have to convince me that Rails is good, I just take umbrage with some of its complexities and with the people who sell it as being simple and easy to learn. In the meantime, I’ll keep ranting.”
I understand his response and understand that he was probably frustrated when he wrote the post and he is not really apologizing for it. That leaves me to still consider my criticism valid that I believe that he faced the problem all wrong (or at least described a method that did just that).
To me, you learn the basics of the thing. You see what skills you have that you can already reuse (HTML, CSS, JS, SQL, whatever). Then, you pick up what you need, working with the “training wheels” that the frameworks or languages give you. Then, steadily over time you start to grow and move deeper in the tooling until one day you are someone that others look to for advice.
That’s the only way we’re going to make it in this crazy development world.
Raymond Chen recently wrote a blog post where he talks about blocking shutdown in Windows versions since XP, and – being Raymond Chen – also the history and the why of certain decisions coming out of Redmond. This blog post was picked up on Reddit and people are slamming Windows for every possible thing.
What is interesting is that these people, who are suggesting that “Linux never had to do this”, just don’t get it. Linux is getting better, but it is *still* not user friendly. 90% of the people that work at companies that I’ve worked at could not run Linux without a lot of help. My grandparents couldn’t use Linux without a lot of help. Windows is generally easy to use.
If I generalize a bit, it almost seems like operating systems have their own “magic triangle”. You can have inexpensive, stable, or easy to use… pick only two. Linux is inexpensive and stable. It is free for the operating system and it runs on almost any hardware you can get, but it is NOT easy to use for the average “non geek”. Mac is stable and easy to use. It is known for all of its “user experience” and “it just works”, but it is not inexpensive. Once you own Mac hardware, upgrades to the OS are inexpensive, but to run the OS, you need expensive hardware. There is no good $300 Mac option.
Windows, on the other hand, is inexpensive and easy to use. It is growing more stable, but it still has a lot of quirks, particularly due to being able to support tons of hardware and tons of decades-old software. But easy and cheap is a tradeoff that many users are going to take. Because of that, Windows is going to have a place in the market for years to come, even if its marketshare will continue to erode as the marketshare of the desktop itself erodes.
But my theories about operating systems aren’t the point of this post, they are merely the backdrop. The point is that “nerds” (programmers, sys-admins, geeks, and all computer-savvy types) don’t sympathize enough with the average user. The computer elite just dismiss the average user as “dumb” and wonder why they can’t just remember to type “sudo apt-get install flashplugin-installer” to install flash on their system.
Remember, there are users that take classes on how to use Microsoft Word! They need lessons in “Saving a Document”, “Performing Cut and Paste”, and “Changing the Document’s Font”. I’m not mocking them for this, I’m pointing out the reality that these people are dealing with. To ask them to understand “sudo” and “apt-get” or scavenging the web to find some “driver” for their video card (“what’s a driver”, “what’s a video card”) is asking too much. They just want to get on Facebook, do their taxes, check their email, and watch movies or YouTube. What makes sense for we Nerds does not make sense for them.
Building up that sensitivity to the plight of the average user will make you a better IS/IT person. As long as the prevailing opinion of computer geeks is that the user should be able to perform these <my_sarcasm>easy</my_sarcasm> tasks, people that sympathize with the user are always going to have an easy time finding employment.
I’ve said this before, but I feel like it is one of the most important things I can say to the professional developer/IT pro: “We are in the business of solving other people’s problems”.
Solving other people’s problems doesn’t mean solving them with what works for us. It means giving the best solution for them. It doesn’t matter if you work for a product company or in-house enterprise development. You need to create solutions that meet your customers where they are. The sooner we realize that these things are not always in alignment, the sooner we will delight our customers with the solutions that we suggest and build.