Everyone is thinking why in the world would anyone pick static, when you can be dynamic, so much more agile bro. Usually the thought process is what language am I most proficient in, that can do the job. Totally not a bad way to go about it. Now does this choice affect anything else? Testing? Speed of development? Robustness?
We have successfully assigned a value to variable without declaring it before hand. Simple enough, try doing this in Java (you can’t). This can *increase* development speed, without having to write boilerplate code. This can somewhat be a double edge sword, since dynamic languages types are checked during runtime, there is no way to tell if there is a bug in code until it is run. I know you can test, but you can’t test for everything. You can’t test for everything. Here is an example albeit trivial.
Now if you are raging to some serious dubstep, its easy enough to miss that small typo, you go screw it and do it live, and deploy to production. Python will simply create the new variable and not a single thing will be said.
Many argue this increases robustness as well as decrease chances of Runtime Errors. Since the compiler will catch those horrible horrible mistakes you made throughout your code. Your methods contracts are tighter, downside to this is crap ton of boilerplate code.
Traditionally languages may place restriction on what transaction may occur for example in a strong typed language adding a string and integer will result in a type error as shown below.
Regardless of where you land on this discussion, claiming one is better than the other would lead to flame war, but there are places where each is strong.
Dynamic languages are good for fast quick development cycles and prototyping, while static languages are better suited to longer development cycles where trivial bugs could be extremely costly (telecommunication systems, air traffic control).
For example if some giant company called Moo Corp. spent millions of dollars on QA and Testing and a bug somehow gets into the field, to fix it would mean another round of testing. When sitting in that chair the choice is clear static languages FTW, its a hard job but someone has to milk the cows.
Just a little food for thought, for when you are starting your next project. You never know what limitations you maybe placing on yourself and your team.
2011 has been an extremely fun year for me. I have met a lot of new people, built quite a few things. Experienced failure, learned a lot. I believe everyone is by product of all things they experience or force themselves to experience. You think you may know something because you read about it, trust me experiencing it for yourself has no comparison.
As I look back, I am getting better at building things as the timeline will hopefully show.
All of this work has been done outside of my 40-55 hour work week job in software security. No excuses.
TL;DR
I built a few things. Learned from my experiences. Links to those things and the people I worked/debated with below.
Dusty Programmer
This maybe soo META, but this blog itself has been a integral part meeting a lot of people I have worked with on various projects. When I first started writing, I knew having a clean and working design would be essential. I had admired the work of Serena Ngai, content maybe the king, but design is certainly what wins people over. So I emailed her. I didn’t know her. She didn’t know me.
It was a pleasure collaborating with her on the design. I would eventually work with her again.
Once that was completed. I began several write ups on various topics, that I found interesting which rung in with the developer community on Tumblr, the blog grew and grew.
Then one day in passing I wrote a simple blog post about, How much bandwidth was used with Tumblr ASCII art. It took me about 45 minutes to write. I did most of the math in a Google search bar. As I was writing the blog post. I submitted it to HN, it was well received. I think.
That was actually the first time, I got reaction that strong from anything I have ever written. That being said, Justin is still in ICU and we expect him to make a full recovery in the new year.
That being said here are the best articles from the year of 2011.
I learned a lot about how people consume information, and what resonates with people. Extremely interesting to me. Things like bounce rate, are ridiculous when you think about it. I kept trying to do things like linking to the site and passing users to other content, something you will see I have done throughout this post. In case math isn’t your strong suit, that’s over 949K views on those 4 posts. Last month I was proud cracking 1 millions views :)
Takeaways:
- Write.
- Proofread(still working on this)
- Create a brand for yourself.
- Find like minded people.
Prologger
First solo project. I am by no means a designer, but friend Ahmed(developer by trade) claims to be. So he eventually came on to make this releasable with me, Thanks.
I started playing with ideas around achievement systems. I extremely irritated by the way hiring was being done in organizations solely based on claimed skills rather that accomplishments.
So I thought about building an achievement system that would tie in all your online contributions to various projects, if you were the lead developer on a project, if you a big contributor, languages you were proficient in.
So I discussed it with anyone who would listen. This is where I meet a quite a few people. Kenneth Reitz was the probably the first person talked to this about who genuinely got excited about it, this was before he was famous for Requests™. Mike Grouchy was indispensable to me, gave me someone I could talk to about design decisions I was making.
Since building something on your own, can be particularly daunting task, especially when doing most of the development on your own and very very late at night, but I took it as a personal challenge.
So I was building away, the site was quick. But, I was beaten to the punch by coderwall. They were a team. Working on it full-time. My ego would have liked for me to be able to compete but it wasn’t realistic. They had the exact same concept, I am sure they had exact same discussion I had been having with my friends. It was a serious blow to me. I was working super late nights. Then the glory gets all swooped up just like that. Truly depressing, but with failure comes success. So I thought hard about what to do next. So then I thought why not OS the project. I did it was one of the most followed projects on Github that day.
I ended getting a couple of thousand users. It was fun meet a bunch of cool people who were excited about what I built. Learned a few planning and skills and to focus on MVP. Fork it here. If someone wants to clean it up ( it needs seriously cleaning).
Takeaways:
- Your ideas don’t mean anything
- Execute first.
- Open Source is fun.
Courtside
I was quite certain I needed something else to fill up my free time. This came up in a casual lunch discussion with Denis Zgonjanin and Omar Shammas. I had this awesome chicken Caesar wrap. We were excited about the idea of Courtside not the chicken caesar wrap. We knew Django Dash was coming up so we decided to build this for the competition. So to do well we I knew we needed someone who was good designer. Serena popped into mind. I messaged her, she agreed to join in. Everything was a go. Denis was unable to join us since he building his start up eProf. We did build it at his place. There was little sleep had that weekend.
I soon came to realize, I hate coding sprints. They extremely good for getting MVP out the door extremely quickly, but don’t expect a polished product. I like to release things when I feel they are ready, but with coding sprints everything is rushed and slapped together, but it a beautiful experience every developer should experience once.
We had a three way tie for 8th place out of 40 teams it was extremely close. It was the first time we all worked together and our first coding sprint competition. It was extremely fun!
Takeaways:
- Built something cool.
- Worked with smart people.
- Learned you need business people. They aren’t so useless. :)
Bro Did You Hear
I needed something else to create. I think I am funny. I doodle quite a bit. I thought why not put some of this online. I knew I needed to meet more designers. Often times when I want to build something, I lose steam because I know it will be ugly. So I posted to Forrst. I had some many ideas, just no one down to hack on them.
Valentin responded, we then continued to work for the next 5 hours, never having meet in person. We worked well together, site was well received. It was added to subreddit comics. It received quite a bit of traffic, gave me another insight on bounce rates as well. People on this type of site tend to stay longer, in hopes of another laugh. But with my blog often arriving through reddit or HN, they would quickly consume the knowledge and move on. Problem I have observed and yet to solve.
Takeaways
- Learned more about traffic and people.
- Made a new friend.
- Hype can do magic.
- Do what you love to do.
Notewagon
Once I had released a bunch of the projects. I started to realize that I need to consolidate my efforts into producing things outside of the fact of me just building them. Everything I have built I have learned something through each of those experiences, but those returns were diminishing.
I was thinking about building a Note sharing tool for the university I went to. My one friend had started something similar and told me about the Notewagon guys. We started talked and since then I have been working with them. That’s why I have been off the radar for the past couple of months. :)
Takeaways:
Conclusion
If you think something is cool. I am sure there are other people out there who do as well. It’s your job to find them. Build a brand. Be kind. Be passionate. Be awesome.
You can do anything you want to do. Work hard. Oh I can’t I have no time. bullshit. You rather be lazy and sit around. Focusing your efforts is the thing I have learned the most this year.
I wish I could list everything I built. If you want to see the complete list. Tweet me here, or follow me here on Github.
We will see what next year holds. :)
Discussion
Every single day we are required to do some repetitive tasks, like clean up old data files or run some commands on some servers, and collect X.
Now you can go about this in two ways, do it manually or write a script that does it for you. The generally accepted rule of thumb is to write a script for things that you will do more than twice. Is that really true? If I am going to collect metrics a few times; is the time that i invest into writing a script really worth my time?
Some would say yes, but in my experience I always find myself seconding guessing myself and I often spend time really thinking about if writing the script will save me time in the long run. So you can clearly see where time is being spent.
As you can see this has become and an issue, I am not even including the soul crushing regret that when you realize you should have written the script (grrrrr). Now what is the solution to all your problems? What is the one question that you can ask in order to determine if you should write a script or not. Unfortunately like all things in life it depends. Here are some questions to ask to determine if you should.
- Can you get a significant amount of work done while the script is running?
- How long will the script take to write?
- How many times will you be doing said task?
- Will you learn something new?
This is just what I found useful. I would love to hear your thoughts on this.
Discussion