So, we looked at JPEG image encoding, which is a very popular image codec. Especially since our image is going to be blurred heavily on the client, and thus band-limiting our image data, JPEG should compress this image quite efficiently for our purposes. Unfortunately, the standard JPEG header is hundreds of bytes in size. In fact, the JPEG header alone is several times bigger than our entire 200-byte budget. However, excluding the JPEG header, the encoded data payload itself was approaching our 200 bytes. We just needed to figure out what to do about that pesky header!
1. Given what I know of this person’s performance, and if it were my money, I would award this person the highest possible compensation increase and bonus.
2. Given what I know of this person’s performance, I would always want him or her on my team.
3. This person is at risk for low performance.
4. This person is ready for promotion today.
Before I started using this method, I always struggled with ways to highlight parts of code I wanted to talk about when giving presentations. This method, I’ve found, is at once the easiest method to use, and provides context to the viewer. They can easily follow along, and where the code is in relation to other code you are talking about is made apparent.
A picture is worth a thousand words, and this one should show clearly how to highlight lines of code on a slide. You just add two shapes, and set the opacity to such a level that code can still be viewed, but it’s dimmed out.
You can also generate nice transitions between highlights of the same code using Magic Move as your transition.
The result is a fairly simple transition as you highlight specific lines of code.
This works with code that cannot fit on your slide as well. Simple add the code to your slide, and allow it to go beyond the edge of your slide. When you want to highlight code that is partially hidden, simply move the text box up.
Other presentation software can do this using their own similar features.
- Practice your talk before speaking. Several times. Record yourself. Watch it. At a conference, people paid $$$ for this.
- Assume wifi is unavailable for your talk. Don’t depend on it to run demos.
- Assume you’ll get few or no questions. Given a 45 minute slot? Aim for 40 minutes.
- If you insist on live coding, make sure you’ve written down the code ahead of time. We don’t want to watch you debug in real time.
- If your talk title says it’s about X, don’t make the first quarter/half not talking about X. We probably came to listen to you talk about X, not your life story. Exceptions exist, but do so carefully.
- Waiting for audience participation is awkward. “Can anyone see what’s wrong?” Just move on.
- The best slides are ones that are useful after the talk. You can export with speaker notes! Have speaker notes!
- Be professional. Know how your computer works. How the presentation software works. Show up ahead of time, make sure tech is ready.
- Don’t save your talk for a big conference. Run through it at a user group or meetup. Adjust. Improve. Repeat.
- You can’t please everyone. Present for a target audience. Title and description should aim to entice that target audience.
All too often on Hacker News, I come across a comment like this:
wouldn’t most of them be able to build something like this for internal use in a single day
Yes. Of course, it might only take a day to build, but it will be maintained forever. And that means dealing with potential bugs. That means testing. That means deploying. It means having a way to manage it. A way to scale it up. This means adding features as needed. And of course, still dealing with new bugs. It’s another system, another cog that you have to maintain.
So, next time you need to create a tool like this, stop and think for a moment. Is this built? Does this exist out there? If so, consider using the service. However, if what you need doesn’t exist, than maybe, just maybe, you’ve found yourself a new idea.
What to do:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
How to do it:
When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
From Agile Is Dead (Long Live Agile) by Dave Thomas.
Last year I read 37 books. I don’t pretend that this is a high number. I know that there are people that read far more books than that. However, I also know that 37 books is far greater than the majority of other people. Still, it’s important to note that I don’t read all these books sitting down turning pages. Rather, I read the majority of them as audio books from Audible. You might consider that cheating, but I don’t.
I listen to them in my car on my way to and from work. With an hour commute, I get a lot of listening time in. I also take the books with me to lunch. It gives me time to get out of the office and to take a breather. I get to catch up on a good story. It’s a great break in the middle of the day.
I’ll go for walks, and listen to a bit then, or when I’m washing dishes, or doing chores. When others might listen to music, I’ll put on my ear buds and listen to my book.
I don’t read all my books that way. I still love real physical books, and I also enjoy e-books on occasion as well. But if one of your resolutions this year is to read more, I highly recommend audio books.
Understand and respect your users
You are building something for someone. Whether that someone are other people just like you, people mostly like you, or people completely different from you, you need to understand your user. This also means that being a better developer isn’t a once-and-done event. It’s something you have to constant work at.
So, next time you get a project, care about the user. Understand the user, and make sure the software is the best possible product you can create for that user.
We easily forget how even the simplest of things that we can do are magic to so many others. That means we can’t just make them happy. We can’t just give them what they want. We have to give them the best experience we can. Great programmers can do that. They know their audience, they know the needs of the users, and they work hard to give them the best experience.
This is true for both GUI applications and libraries and frameworks. We’ve all had the joy of working with code that that was elegant to use and well documented. A well defined interface with solid documentation is a developer caring about his user: other programmers.
So, care about your users, whether they be other programmers or people who don’t know what a browser is.
Know your limitations
The best developers know they can’t do everything, and they also know what they don’t know. They aren’t afraid to ask for help, or to talk things over. Those great developers you know discuss and plan, and rely on a great team. If you want to become a better developer, you need to be willing to admit when you don’t know something.
This means asking questions when you are unsure. Checking your ego at the door, and being comfortable saying “I don’t know” or “I’m not sure.”
One of the hardest things for me to do is to ask for help. Which is silly, of course, because whenever I’ve asked for help, those I’ve asked have been more than willing to help. What I’m really afraid of is looking weak, like I don’t know what I’m doing, as if I don’t belong. It takes a real effort to remind myself that it’s okay to ask for help. That I don’t always have to have all the answers. That the best solutions I’ve ever come up with have been when discussing the topic with others.
This also means letting someone else take they lead when they are clearly better with a certain skill-set, and learning from that person. I don’t mean that you pass the problem off to them. What I mean is, don’t be afraid to adopt someone else’s solution. A part of you might think that it will highlight the fact that your solution wasn’t as good. What really happens is that you recognized that your solution could be better, and because you were stuck, you sought a better solution. And now you get to implement a better solution. And that better solution makes for a better experience for your end user.
And in the end, that’s what matters.
Challenge your limitation
Once you know your limitations, it’s important to try and break through those limitations. The obvious solution is to learn what you don’t know, and I cover that next. However, not all things are as simple as reading a book, finding an answer on StackOverflow, or finding some article on a blog.
In many cases, it’s doing things. Later, I talk about teaching. However, if you are afraid of speaking in front of people, or you aren’t comfortable doing it, you’ll be less likely to teach people. Granted, you could go the route of doing it from the comfort of your own blog, but you’ll be living within your self-imposed limits.
This means never saying you can’t. It’s fine to say you don’t know how, or you’ve never done something. And the more you do, the harder things will get (because I assume that you’ve tackled a lot of easier things along the way). But challenges and difficulties shouldn’t stop you. You should look at every challenge and difficulty as an opportunity. Treating them as opportunities puts you in the right frame of mind. One of overcoming those challenges and limitations.
This should come as no surprise, but at the end of the day, you also need to keep learning new things. There are many professions were constantly learning is the norm, and programming is one of them. You can, of course, stagnate, and not learn new languages or tools. You can allow yourself to fall behind the curve. But sooner or later, those new tools will become the norm, and you’ll be playing catch up.
This doesn’t mean you invest equally into all new languages and tools. You have to pick and choose what you are investing your time in. There are far too many new technologies coming out these days for you keep up to date on everything. However, many of these technologies are based around well-established principals.
The mobile-side should be equally obvious. These are two areas that are growing, and as we see wearable technologies come out from Google, eventually Apple, and others, we’ll see an increase in the demand for knowing how to work on these mobile platforms. iOS and Android aren’t going away anytime soon, and knowing how to write applications for them will only make you a better developer.
It’s equally important to teach others. I’ve covered this briefly in my article on the benefits of speaking, but teaching forces you to learn the topic well enough that you can teach it to others so that they can make use of it.
As a developer, you might know a lot of frameworks and how to use various languages and editors, tools and systems to make yourself more productive. But until you’ve actually taught people how to use these tools, can you really say you know them? After all, at the comfort of your desk, you have Google and StackOverflow at hand to handle any problems you might run into. You can stop to check email, go get some coffee, and otherwise ponder what to do next.
But when you are teaching, you really are on the spot. Every eye is on you, and when someone asks a question, you either know it or you don’t. There is no harm in not knowing an answer to a question. But you have to admit it, and quickly. You have to humble yourself, because to give the wrong answer is the absolutely wrong thing to do at that point.
Is that all?
I’m not going to pretend this covers everything you can possibly do to become a better developer. However, I do know that these are things we should always be practicing. I’m curious if you have other things developers can do to better themselves.
I’ve thought a lot about performance this past year. Both on the client side and the server-side as well. While it might not come as a surprise, the number one thing you can do to improve performance is to do less.
And this applies to most everything that you can actually do.
Code should do less. The more your code has to do, the longer it’s going to take. Obviously, not all operations in your language are equal, but beneath the covers, the computer has to do more.
But we need to do more
That network call out to Facebook has to do a lot. It has to travel a larger distance than keeping things local. It has to perform DNS lookups, or it has to wait around for the remote machine to do more stuff.
When that user signs up and you decide to send out that email? That’s doing more. Fetching something from cache that you’ve already got in memory? That’s doing more than you should.
It seems obvious, but at every step, you should seek to do less. And the problem is that while it’s obvious, it’s something we overlook. We forget that every action, every line will add to the cost of running the program. And no, I don’t mean that one line is equal to another. As I said before, it’s what’s happening beneath that really matters.
Of course, you can’t help but do more. After all, first it was just a simple sign-up. Then you needed to send out an email. You also needed to update the mailing list database on sign-up. And now you need to run another set of operations for fighting spam.
The Solution to doing more with less
The easiest solution to doing more is to not do more when you would normally do it. Push what you need to do off to a later time. Either using a messaging system like RabbitMQ or even later using crons, you can probably find something that will suit your needs. The best part is, if you architect it that way, instead of adding more code to the part where you’d normally add it, you are instead just adding code some place else, listening for that event.
This really emphasizes the Open-Closed principal in SOLID. Open for extension, closed for modification. Every time you find yourself modifying existing code to add a new action on a particular event, ask yourself if you really need to have that action take place at that exact time. Ask yourself if all the other processing should be held up waiting for that action to take place.
I used to have a problem learning new programming languages. It wasn’t that I found the syntax difficult, or that concepts eluded me. Rather, it was the idea of learning an entirely new language a fairly time consuming task. It hasn’t been until recently that I’ve come to accept that my definition of what learning a new programming language means was wrong, or at least poorly thought out.
What learning does not mean
First, let’s clearly define what learning a new language really means. For a long time, I always assumed learning a new language meant understanding the ins-and-outs of the ecosystem surrounding the language. What I mean by this is best explained in an example.
If I said I knew Objective-C, I’d most likely mean I know iOS development. Of course, one can know Objective-C without knowing iOS development, so I’d make sure to write both Objective-C and iOS development down. But when I said I knew Objective-C, it meant I also understood the tooling around it. I understood how to use Xcode, I knew the ecosystem, how to write Podfiles, I understood the various blogs and communities surrounding Objective-C. I would also use Objective-C as the implication that I knew the Cocoa Touch framework (helped along by using iOS development). The idea here is that I knew much more than just Objective-C. And learning all this stuff couldn’t happen in a few weeks.
How people can learn in a few weeks
So, using this as a standard, I always shook my head whenever someone would talk about picking up a new language in a few weeks.
“A good programmer can pick up a new language in a couple week,” was a mantra I never quite agreed with. The problem, however, wasn’t the mantra. It was that we were defining what was being discussed in different ways. A programmer can pick up a language in a short period of time. Especially in an environment where there is support for that language. Take any language you sort-of know, and put yourself in an environment where you are working alongside people you’d consider experts in the field, and you’ll probably agree that you’ll pick up the language fairly quickly.
At the end of those few weeks, you’ll be productive. You won’t be perfect, and you’ll still have much to learn, but than we can use that to describe anyone, really.
What learning a new language means
When looked at through those eyes, learning a new language is really a matter of understanding how to use the language to be productive. It doesn’t mean you understand every nitty gritty trick. Rather, it means you know enough to move forward. You have a foundation in that language.
If asked to write a program in that language, not only could you evaluate whether the language was suited for the program, but you would know where to start.
When looked at in that light, learning a new language becomes a much less daunting task.
How to learn a new programming language quickly
This is the part of my article where I make a bold claim. That claim is “quickly.” However, the idea is sound, and not originally mine.
The quickest way to learn a new language is to implement a program you already know how to build. The classic example for the web is to build a blog. You already know how to build a blog. There is a good chance if you are a web developer, you’ve built one yourself at some point. So, by building a blog in your new language, you are focused on the language, not the problem.
Now, don’t get stuck up on building a blog, as this is just an example. Your program for learning can be anything you want. It can be an IRC bot, a mail client, or your own personal image upload server. It can be a Twitter client as is popular with iOS tutorials, or it could be a game server for tic-tac-toe. The point isn’t the program. Rather, it’s that it’s complex enough to incorporate multiple technologies you’d want to know.
Going back to our blog example, you could say that the blog needs a database, thus ensuring you’ll need to learn how to connect to various databases. You’ll need to learn how to cache those results, so you aren’t connecting to the database when you don’t need to. You’ll need to handle data input, comments, and tempting. You’ll need to understand quite a bit, but it’s not difficult enough that you are caught up with what you are doing. Rather, you are focused on how to do it in the language you want.
A new year
With the new year approaching, I’m sure there will be a lot of people resolving to learn new programming languages. Instead, I’d like to challenge you to change your thinking. Don’t learn a new programming language. Rather, write a program in a new programming language.