Really, it’s all in here. I don’t do an enormous amount of hawking my book on this site, but the other day, I realized that I’m doing a disservice by not pushing you into buying it. Why? It’s not because I want your money. Buy it from Amazon for only $18.96 and it will pay for itself. How does it pay for itself? I’ll enumerate some of the reasons:
- Don’t screw up another interview, get the next job you apply for.
- Once you get offered the job, you’ll get a better salary and/or benefits by using some of my tips for tactful negotiation.
- You’ll improve your organization with your leadership skills you get by following some of the ideas on organizational and personal habits.
- You’ll keep your nose clean by avoiding risky practices that can get you in trouble with human resources and management.
- You’ll understand marketing and sales better and learn to work more effectively with them by understanding that it’s a partnership, not a leash.
- Your place in the software organization will improve because you’ll realize that it’s not just your coding that counts, it’s the intangibles as well.
It took me a long time to realize that my biggest benefit to my employers wasn’t my coding skills, but my leadership and big picture knowledge. The sooner you read this book and come to the same realization, the sooner your career takes another step forward.
What you see might be indicative of what you don’t see. I was looking for some software today to use at work. I had it narrowed down to three choices, based on recommendations from people on various websites. I read numerous comments and finally went to the three websites to investigate for myself.
Two of the products looked slick and their websites were polished and helpful, including documentation and screenshots for the product. The third one, the most expensive of the three (although it was still pretty cheap) had the weakest website, relatively little information, no screenshots, no documentation – in other words, very little to instill confidence in me that they would have useful documentation or that their product would be complete either.
In an ideal world, I’d have time to thoroughly investigate all three products regardless of their initial presentation, but I needed to get my job started and if my first impression was bad, and I still haven’t found the other products useful, then I’ll give them a second shot later.
In the meantime, I needed some documentation to help get me started. I found examples on the websites of the other two products and lists of features so I knew I wouldn’t have to leave the comfort of their environment to start using some command-line interface. Yes, I’m a programmer, but I don’t go looking Toolsfor excuses to do more work than I have to. If I can find a simple, easy to use UI that makes a job clear and easy and does all the messy work in the background, I’m in.
It should be common knowledge by now that smaller functions are generally better functions. It may well take the same amount of code to get the job done, but by subdividing the functionality into small functions, you have more opportunity to reuse the code. Additionally, it usually makes it easier to modify the code as well.
This past week, I was adding some functionality to the IDE that I’ve been developing for uCLinux development on Windows (it’s called Fusion – see http://www.fl-eng.com/products/fusion/). The current version supported application development in the form of one executable or library at a time. We wanted to support the concept of a solution, so that you could have several libraries or executables in the IDE at the same time. After looking at all of the locations in that code that would be affected, I guessed that it would take me a couple of weeks to add this and make the other modifications to the existing functionality.
Fortunately, I’m a big fan of small functions and C#. The small functions let me make some quick modifications to the application-development specific code in Fusion so that it could accommodate solutions. Adding new functionality allowed me to reuse the small functions that I already had and I created some new task-specific functions to help with the job. Finally, C# helped me by providing some awesome XML import export functionality.
I can’t speak highly enough about C# and Java in their inclusion of UI and base functionality that just lets developers write the new code without having to reinvent the wheel. By the same token, every time you write a small, self-contained function that does a particular job, you do the same thing to your own code base.
A few weeks ago, I had a project where I switched from the comfort and all-encompassing world of C# development with Visual Studio to Linux land. It reminded me of programming in the dark ages. Opening every file in a basic editor that knows nothing about the code. No code completion. No “Go To Definition” or “Find in Files” (grep? seriously?). No bookmarks. The constant switching between gedit, command consoles, and file browsers was exhausting and time-wasting. My friend Steve was just accustomed to it.
I started researching an IDE. Since we were running “make” to do cross-compilation, I wasn’t worried about integrating the build process. Still, I wanted to see if I was crazy or if I was right that an IDE would help me focus on the job at hand rather than on finding the right code to modify. After much reading, I settled on something small and easy to install that several people recommended – code::blocks. It has the basics of any reasonable package: projects, solutions, bookmarks, easy switching between files, Find in Files, etc.
Suddenly, even though I was in the world of C, which is light-years behind C# development (no flames, please), at least I could work more productively. I know that die-hards will probably use vi or emacs (I was a big emacs user back in my unix days) and using all the basic tools available in unix/linux, but I think they’re missing out on the possibilities of not needing to do it all yourself. Let an IDE give you a hand. It’s not a crutch to lean on, it’s a step stool to start from.
I’m still working on my project to restructure the application where the original programmer cut and pasted thousands of lines of code. So far, my fellow programmer, Steve, and I have eliminated over 100,000 lines of code. In the process, we’ve improved performance and added functionality.
So, what are the important things mentioned in the title of this post?
1. Write decent code in the first place. How?
- Make good base classes to hold common functionality.
- Constantly design and refactor code to keep it flexible, reusable, modifiable, and understandable.
- Comment your code! It’s usually obvious when a comment is out of date or inaccurate, but the value of an accurate comment, especially for confusing or complicated code is immense.
- If you think you need to copy a fragment of code, think about putting it in its own method, base class, or separate class.
- No, you won’t think of everything. We all write code that we later regret, but the closer you get to good, the easier it will be to get to excellent later.
2. Think ahead. That doesn’t mean that you should build in tons of functionality you don’t need now or may never need. It means being conscious of what could come in the future. Using reasonable data hiding to keep internal functionality flexible is a great way to start. If you expose all of your data directly to other code, you have more places to change it if you find performance bottlenecks.
3. Stay creative. Even when you’re working from a specification or set of requirements, you often have some flexibility in your coding. Some amount of flexibility is usually included in the functionality. If you work on consumer software, there’s usually a lot more flexibility. It can’t hurt to bring it to someone’s attention or sometimes, to just go ahead an implement it.
4. Think globally. It’s not just your code and your little part of the world. Your personal value increases when you pick your head up out of your code and look at the application as a whole. As long as you don’t step on everyone else’s toes, you’ll make the whole team look good.
Looking for the perfect gift for a programmer or software engineer? Try Design, Code, Test, Repeat. It’s a fun, funny, and helpful read.
Now, on to today’s post. I recently started working on a new project which involves modifying a large application. After talking with the boss about what needs to be done, the first task became obvious. The large application needed to get smaller.
To give you an idea of he horrors in this project, let’s start with the UI code. There are three types of interactions you can have with the UI and they all look similar, but with slight modifications. This UI is essentially duplicated for two units which you are interacting with. So, what’s the best way to handle this? Well, any normal programmer would write a bunch of methods or subroutines and divide the work, reusing the common code and making some exceptions here or there. Or you might want to create a few classes and use some object-oriented way of differentiating the mechanics.
But, no. Here’s what our hero did: he copied all of the code. So now, there are five extra copies of a ton of code that need to be maintained and modified for future work.
Next, there is a massive amount of data that is read from a database, put into an in-memory structure, and then set in the UI. When the user wants to save, the data is read from the UI, put back in the in-memory data structures, then written back to the database. There are hundreds of possible pieces of data to read and write. Is any of this work done with a clever class or technique that uses a lookup table(s) or some other maintainable/enhanceable manner? You already know that the answer is: no. It’s all done one piece of data at a time, copied five more times.
I won’t tell you that I haven’t copied code; of course I have. But, all of us have our tolerance for doing this. Every time I copy a small section of code, I think, is this the time to add a method or class that does this job? If it’s a large chunk of code, the answer is always yes. If it’s just a few lines, I’m likely to say, next time for sure.
Here’s the real issue. If you find yourself having to repeat the same procedure constantly to handle differences in names of data and their UI counterparts, it’s time to get creative. I’ll be doing this shortly and I’ll let you know what I come up with. Be sure it won’t be a copy and paste answer.
I do double duty writing – software and fiction. Some days I find myself more productive than others and it’s usually due to one thing – my internet connection. It’s not what you think, actually. Most of the time when my connection is good and I have several tabs open in my browser, my productivity sucks. I keep waiting for something interesting to happen: an email from a colleague or friend, a good post on one of the blogs I follow, a good link posted on facebook, etc.
It’s too easy to while away a spare hour with this crap (let’s face it, it’s not a productive use of time.) I find myself most effective when I shut down my browser. That way, I can’t even notice that a new email has arrived (it’s probably just spam anyway). No matter what work I’m doing, if I don’t need the internet to do it, I’m probably more productive not even being distracted by it.
A while ago, I had a discussion on the Comments section of Coding Horror about email. The issue was about whether to send and read emails versus calling, and this leaked into the issue of checking email all the time. The person on the other end of the discussion said he wasn’t distracted by looking at his email because Outlook pops up a little message in the corner of his screen when a new email arrives. The problem with that is that it still interrupts your flow and writing anything is all about getting into flow. It takes time to get your brain fully focused on an activity and any interruption, however slight, can keep you from operating at optimal capacity.
If you think you’re operating at full capacity, try shutting down your browser for a while and working and see if you get more done. If you don’t think you’re focused enough, do the same thing. I’ll be your productivity improves.
As a computer science major, you have certain advantages over other students. You have ready access to the technology that’s used in the industry. Unlike some types of engineering, you can build worlds entirely inside of the computer that’s probably sitting on your lap or at least on your desk.
If anything, it should also be clear that the next billion dollar idea might be only a few days coding away (think Facebook). That’s not to say that you’ll make your fortune in software. Most of us don’t become millionaires, but most of us do make a good living and it’s hard to think of a more flexible, enjoyable one at that.
In school, however, it’s easy to get lost in the just the coursework that you’re given and not think about the endgame (getting a job), but in fact, you have many opportunities to make that easier as well. Each project is an opportunity to put a principal into practice. Every homework assignment that involves writing code is a chance to practice the art of writing code.
The first step towards your career in software, starting from college, is to think about each class and each project like a something you did on the job. When it comes time to write a resume for an entry-level software job, yours can stand out as more than a list of classes taken. Add these projects to your resume and it will look like the resume of someone who has actually done something, which you have.
Next stop: side projects, internships, summer jobs, and volunteer work.
Don’t forget to buy Design, Code, Test, Repeat. It’s a fun, funny, and helpful read.
In one section of my book, I talk about taking a step away from your desk when you’re trying to figure out a tricky solution to a problem or are trying to think creatively. If you don’t believe me, here’s an interesting article about different types of thinking.
I solve most of my creative problems and have most of my epiphanies when I’m not staring at the computer screen. That’s not to say that I don’t come up with good stuff when I’m actively working – I do. But it never ceases to amaze me how many great (well, I think they’re great, just allow me that) ideas I have when I’m taking the dog for a walk, taking a shower, or sitting at the dinner table – anytime I’m letting my mind wander.
Just yesterday I had an idea for a new project at the dinner table, then I came up with some more ideas related to it when I was watching TV later in the evening. Next time you have a tough problem, try taking a break and taking the pressure off yourself. Talk to yourself – explaining the problem to yourself or someone else can open up these same creative pathways.