Three weeks ago my (ongoing) Stackoverflow endevaour finally began impacting my real-life when I started my Internship at InishTech in Dublin, Ireland. It’s a really fortunate incident I met one of their devs on SO and was offered this position after a short follow up. Now that I’m here I cannot express just how much this internship exceeds my expectations.
So what the the hell does InishTech do then? Let me just quote that from their web presence:
InishTech provides Software Developers and Product Managers globally with code protection and licence management solutions to protect their most valuable assets and enable them to provide their customers with the ability to deploy and use their products in the most flexible manner possible.
I’m working on a top secret project to bring support for all the new constructs CLR evolution brought along to their Code Protection solution. Here’s what it does:
Using a unique technology from InishTech called Code Transformation, the InishTech SLP Code Protector takes selected DLL’s and functions within the DLL and virtually compiles (or transforms) them into a vendor-specific format called Secure Virtual Machine Language (SVML). The functions that are transformed to SVML format appear like regular MSIL functions (in terms of interfaces), but are much harder to reverse engineer. Furthermore, SVML runs on top of the .NET platform (CLR), to help ensure interoperability and code optimization.
If you now think “hey that’s cool!” I can assure you it definately is. Working with low-level stuff like this involves a lot of knowledge about CLR internals and is deeply technical but highly interesting . What I’ll be discovering on my way (and have already discovered) will likely be shared on this blog, so stay tuned for some interesting stuff on CLR internals.
Ok, so how’s it like being an Intern at InishTech? It’s great! Let me give you a few reasons why:
- They took care of organizing my accommodation and helped me with all the usual relocation troubles (public transport etc.)
- Modern, bright office in Central Dublin. Two beautiful parks are just around the corner.
- Dual monitors for every developer, cutting edge hardware (QuadCore, 8Gb), ergonomic chairs
- Agile development process paired with a passion for high quality code
- A great team that is dedicated to constant self-improvement in technical skill and process
- Joel-Test Score: 10 out of 12 (sums up all the above points)
- Doughnuts every Friday, Social activities (FIFA WM, Pub strolls…)
I could probably continue like this for a while and still forget all the small things that make it a great company to work for. Oh, and they’re hiring too.
Clean Code: A Handbook of Agile Software Craftsmanship
- Paperback: 464 pages
- Publisher: Prentice Hall; 1 edition (August 11, 2008)
- Language: English
- ISBN-10: 0132350882
- ISBN-13: 978-0132350884
The book can be roughly divided into three major sections with an additional “Prologue”.
In the Prologue the Author and several guest authors explain their personal definition of “Clean Code” and why dedication to write the best code you possibly can is so important for the individual software developer.
The first section (Chapter 2 -13) describes a set of best practices for writing readable and elegant code. The topics covered range from basics such as variable naming and formatting to recommendations for structuring classes and systems. The reasoning given for each of the recommendations is detailed and comprehensible.
In the second section Martin dissects three code samples and walks the reader through his series of refactorings as he tries to transform the code into a cleaner state. While valuable, the format makes it difficult to follow the changes being made.
The third section contains a set of “code smells”, similar to those in Martin Fowlers seminal work “Refactoring“.
Opinion and Conclusion:
All guidelines presented are reasonable and well-defined. I got the most value out of the book by reading the first and the third section, while I found the section with the sample refactorings very tedious and not all too helpful. However, comparing the code before and after the refactoring helped to gain an insight into what kind of improvements can be achieved.
Some of the guidelines are no-brainers and are probably the absolute minimum every passionate software developer should stick to.
However, some of the guidelines left me unconvinced. “A function should only know how do to one thing”. I’m perfectly fine with that guideline and agree with it, but if you take it to the extreme it will make you create three helper methods that are only called from one place. Even worse, you will need to pass intermediate state around (bloating signatures) or introduce artificial state in form of class fields. Not to mention the tight temporal coupling helper methods and the artificial class variables will have. Some of the examples in the book suffer from that “over-abstraction”, I think beyond a certain point readability is actually hurt rather than improved.
On the other hand, the level of abstraction should be high enough so the code is self describing in terms of what it does and should not require additional comments. That’s one of the points that particularly struck me as I read the book: Comments are excuses for bad code, so you should always try to make them superfluous.
In general I could learn a lot from the book and would recommend it for reading. Even if not all the guidelines were 100% convincing, the book helped me learn a critical look at code.
Links and Accompanying Books:
- I’m currently reading http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=pd_sim_b_1 from the same series (thanks InishTech!). I think it’s a very good addition. Maybe it’s even more valuable.