zacharyc

Many moons ago, I got my start in the world of software engineering playing with Ruby on Rails. With a close friend I had basically done the boilerplate for something like rails in PHP for a photography studio project we had done for our database class in college. We were the only students in the class to who were mac users at the time so we didn’t use Access like the rest of the class. We built our own thing and it was awesome. Then within a couple of months we stumbled upon Rails and the complexity of our project seemed crazy compared to how simple Rails was, even back then. ...

The book Naming Things is a book about one of the hardest problems in software engineering, the art of naming variables, classes, methods and functions. This book was recommended on another resource that I’m unable to remember. My general feeling is that this book would have been great earlier on in my software career. Many of the lessons covered are things that I have learned from other books or by making the mistakes myself. If you are thinking about getting into the field or just graduating college, picking up a copy of this book and reading it (which is quick, because it is less 100 pages), would definitely be worth it. If, on the other hand, you have read other coding practices books or spent years writing code, most of the concepts may seem overly obvious. ...

Malcolm Gladwell wrote the book on the 10,000 hour rule, Outliners. This book proposes that 10,000 of work at anything will lead to success at that. That the people who are real masters have spent this time. If you read more closely, there is more than just 10,000. It’s not that anyone who puts in 10,000 hours will be a success, it’s that talent alone is not enough. You need to put in the work as well. And that is the methology that has been ruling my life more recently. Doing a bunch of things a little bit each day will lead to getting better. Trying to put in at least a piece of code a day (including weekends), has been a goal of mine on my github graph. Not all of it is the same language and not all of it is substantial, but I’m trying to write something everyday. ...

I’m in the stage of my career where I’ve seen a lot of projects from other developers. I’ve inherited good code and bad code, and there a couple of big gotchas I’ve been wanting to talk about. Comments Function Heading Comments When I was in college, I used to write three line comments for everything 1 2 3 4 5 6 //------------------------------ // This Function Squares Pi //------------------------------ float square_pi() { ... } While this comment isn’t wrong, it is unnecessary. The function name square_pi says what it does. Putting in the comment adds more lines to the file without providing any real use. Yes, the compiler will remove it so it doesn’t hurt the running code, but it is repeating what is written below and the function name should be good enough. ...

Swift is a new langauge and still being developed. It is unfair to fully compare develping in swift to developing in Objective-C as the language was very well developed before my experience with it. Still, learning and programming in Swift, as a developing language, has some real challenges. The most challenging of which is that Swift versions can change the validity of previous only examples. I’m really working on learning Swift and trying to master the langauge and libraries around it. I’ve been trying to touch new features instead of just staying in the lane of the features I already know. While things like unwrapping Optionals takes a little bit of getting used to, it’s not that bad. The biggest challenge I’ve had is learning the differences in the langauge version. ...