Ben Carpenter

How do you feel about working in strongly-typed languages? I generally like working in a strongly-typed language, at least for bigger projects. As I understand it, there's actually not a really firm definition for "strongly-typed", so I'll just define it as a language where the type of all variables is known at compile time, either explicitly by the variable being declared as such or implicitly by it being assigned a value from another variable which has an explicitly-declared type. There are a few reasons I like strongly-typed languages: 1. You're less likely to get your variables mixed up and use the wrong value for something. For instance, if you have a function that takes two arguments of different types, and you try to pass two objects to it in the wrong order, the code won't compile, and it certainly won't run. In this way, you avoid the grief of getting bizarre behavior due to the runtime environment trying to interpret an integer as a character or...

Clean code. Succinct. Legible. Intuitive. Write your code with others and your distant future self in mind. When you are writing code, please keep it clean. Some nice, well-written code is a beautiful thing. It's easy to tell what it's doing. It's easy to tell what changes can be made so that you can have it do other things. It doesn't force others (or you, if you revisit it down the road) to waste significant brain power trying to wrap their (or your) minds around it. Some things to do to keep your code clean: 1. Use small functions which only do one thing. If a function is getting too big, it means there's too much going on and it won't be easy for a reader to understand what's happening in it. This can be done to taste, but I've been told that around twelve lines is a good max. 2. DRY (a common, though sometimes disputed principle - don't repeat yourself). If you're writing the same code in different spots, it can be hard to maintain. If ...

When you come up against a problem to solve and you don't know how to solve it immediately, you have two choices: 1. Ask for help. 2. Don't ask for help. Technically, these two options complement each other, so as long as you have the asking ability, you always have that choice. Whether you know how to solve your problem immediately or not. Or whether you'll be able to solve it eventually or not. Or whether you have a problem or not. But lets not dwell on technicalities. Benefits of asking for help: 1. It can be the most efficient way from where you're at to where you want to be. An expert can give you the answer, you can implement it, and you'll be all set. 2. It can be less confusing. If you have to sift through a lot of documentation or search engine results, you can get a lot of unnecessary information that can cloud your reasoning and planning. When you ask an expert, they can see what you're dealing with and tell you only the information that's rele...

In a previous post, I talked about automating tasks to save time. Now I want to talk about a particular type of automation that I'm particularly geeked about at the moment: Continuous Stuff (my term, no one else's that I know of - there's probably a more technical term for it, but I don't know what it is). I will note that everything here is lifted from another article I read about a year ago and have been unable to find again and an Interview on the Developer Tea podcast, which I'll reference at the end. There are good articles about Continuous Stuff all over the place, so if you want to find out more about what it is, good practices, or good tools just search around. I would recommend searching for "Continuous Integration", "Continuous Delivery", and/or "Continuous Deployment". There are three levels of Continuous Stuff that I'll acknowledge for the purposes of this post: Continuous Integration Continuous Delivery Continuous Depl...

Being sick stinks. It's uncomfortable. It makes it hard to work. It keeps you from being around people, or at least makes you second-guess being around people, which can be stressful. My recommendation for this week: Don't get sick. And don't get other people sick. I'm out (and sick).

One thing that's nice about being a programmer is the ability to automate your own repetitive tasks. If you need to fill out a time sheet, then add up your hours for different tasks, you can program something to automatically tally that up for you. If you need to run a script on a client's data and send to results to their accounting department every week so they can verify everything is calculating correctly, you can write a small application that will run the query at the specified time, write it to a spreadsheet, and send off the email, such that you don't have to do anything with it anymore. It's a great time-saver and frees up your brain to do other important things. Over time, as you go through the process of doing repetitive tasks and writing software that automates tasks, you'll come to get a feel for what could be made automatic and whether or not it's worth it to implement that automation. Here are a couple of things to consider when deciding whether...