I’m speaking at Houston Tech Fest this weekend. I always have a great time there so I always look forward to it. I’ll be giving the two talks below. If you attend to my sessions, please click the “link for feedback” for the session you attended and give me your feedback so I can work on improving it.
Be a Professional Developer and Write Clean Code (Keynote)
9:30-10:30am (Room 300)
Professional developers must write the best code possible, given what they know and what they have at the moment of writing. After a while, we may look at that code and wonder “wow, what was I thinking?”, and that’s a good thing: it shows we have improved. This session is about my observations regarding code I either wrote or had to work with.
Link for feedback
Beyond the Daily Stand-up: An Intro to Scrum (Keynote)
5:20-6:20pm (Room 304)
Countless companies believe they’re doing Scrum because they have 30-minute daily stand-ups (with people sitting and staring at their laptops) every morning. But Scrum is really a lot more than that. In this session, we see all of the main parts of Scrum (roles, artifacts, and events), and we also talk about some real-world collaborations in teams who adopted Scrum.
Link for feedback
Whenever I’m not giving a talk, I’ll most likely be hanging at the Improving booth. Make sure to come by and say hi! 🙂
I’ll be speaking at the Houston .NET User Group (HDNUG) this Thursday, October 12th, at 6:30pm:
Code Review: I mean no harm!
As part of the work I’ve been doing for many years, I get to do a lot of code review. I usually document things that come up doing a code review so I can share it with other developers in the teams. In this session, I share some of the code I’ve looked at, the reasons why the code raised yellow or red flags in my head, and possible solutions I’ve proposed.
This is a fun talk for me and I’ve received great feedback from those who have seen it recently. It’s also going to be the first HDNUG meeting hosted at the new Improving Houston office. So I’m excited!
Here’s the location:
10111 Richmond Ave, Suite 100, Houston, TX 77042
Click here for directions. There’s plenty of free parking right at the location. See you there!
UPDATE: If you attend this talk, please, give me feedback by following this link. It’ll be a big help so I can improve it.
When I first started writing unit tests, I followed the common convention in C# for method naming:
Later, I adopted the convention of separating words with underscores:
At some point I figured the approach above makes the name of the method look like the title of an article. I then decided to go with the same approach, but making everything lower case:
In some cases, I may use uppercase if I want to draw attention to something in particular:
I like when the code is calm to look at, and it draws my attention to things as appropriate.
If there’s anything I do all the time, I try to either find or create a shortcut so I can do it using only the keyboard. Moving windows around is one of those things (maximize, minimize, dock to different parts of the screen, move to different monitors, etc.).
On the PC, I use the combination WinKey+(up/down/left/right arrows). For instance, say I’m working with Notepad like this:
If I want it maximized, I hit the Windows Key + Up Arrow:
If I want it restored back to its original state, just hit Windows Key + Down Arrow.
If I need it docked to either the right or left side of the screen, I hit Windows Key + Left/Right Arrow:
If I want to move the window moved to another monitor, just keep hitting Windows Key Left/Right Arrow until the window makes it to the other monitor (once it gets there, I usually hit Windows Key + Up Arrow so it gets maximized).
On the Mac, I use the SizeUp app, which gives me even more options to manage windows on my screen:
I use these shortcuts all day long!!
As it turns out, I just realized the post where I talk about switching windows layouts in Visual Studio 2017 was dead on arrival. Well, the tips I gave regarding exporting/importing settings and using VCmd to automate some of that is still relevant and useful.
However, for switching windows layouts, somewhere between VS 2013 and 2017 the tool finally introduced something to make that easier:
Regardless of the approach, please consider using your screen real state wisely. I see a lot of developers fighting VS with its several windows all crammed into one screen, while the other screen has either MS-Outlook or a web browser open at all times showing all sorts of useless things that can only steal away productivity and focus.
There are times, however, when I’m doing temporary work at a client’s machine and I don’t want to use my personal SnagIt license, so I use the next best thing: Jing (also by TechSmith). It’s free, and it has several of the main features I use all the time in SnagIt.
Jing has a quick access feature that sits at the top of my screen:
I select the window or area I want to capture, perform some basic annotation, and then either put it on the clipboard (usually to paste it on Evernote) or upload it to screencast.com (free service from TechSmith) so I can easily share the image through a link with other people:
That’s it: simple free tool that I use a lot everyday and makes me more productive. Win-win.
I was asked this question this week: “When did you start writing clean code?”. I hadn’t thought of that before. Pondering on the question, I remembered when I started paying more attention to writing better code. It also made me think when I do not write clean code. Here’s what I came up with…
When did I start writing clean code?
Going back in time some 25 years, I was working with good old Clipper. Some of the files I was working with had thousands and thousands of lines of code. I had to print out pages of code on a dot-matrix printer and then draw lines to connect if-blocks and things like that in order to make some sense out of it.
Eventually, I figured out I could move some blocks of code out to separate functions, so instead of reading 5k lines of code, I’d need to read only 2k. As time went by, that codebase was way easier to understand.
When I do not write clean code
For me, it isn’t possible to write clean code all the time. For example:
- When I’m implementing some new feature and writing tests first
- In a case like this, once I have a failing test, I’ll write whatever code it takes to make the test pass. That could mean having one class with a lot of ugly code. I don’t care. Once my test is passing, then I’ll look back at the nasty code and will do my best to make it better, given what I currently have available (my skill with the programming language, my knowledge of the framework or libraries used, my understanding of the requirements, the time I have available, etc.);
- When I’m new to the programming language, framework, libraries, business domain, project…
- In cases like this, there’s really so much I can do. In the beginning, things will come out a little (or a lot) ugly. As I learn, things will get better.
I remember moving from FoxPro to C#. As much as I though I was a good FoxPro developer and wrote good code, I just know my C# code was terrible. It took a while to learn how to write better C#.
When I moved from C# to Ruby, things were slightly different: I already knew my Ruby code would look bad initially, so I first learned how to write tests! I didn’t even worry about writing clean tests; I only cared about writing some test so I could “write Ruby code with a C# accent”, and once the tests were passing, I’d get help from somebody who knew a lot of Ruby to show me “The Ruby Way” (or more specifically, the Rails Way) for doing certain things.
For me, at the end of the day I just want to make sure I wrote the best code I could, once again, given what I currently have available:
- My skillset in the programming language, framework, libraries, etc.;
- My understanding of the business domain;
- My time available