You need to be able to write. You need to be able to write clearly and succinctly about technical issues. No interesting software is ever built by a team without real debate about the design, and those debates usually happen in written text, via email or design documents. If you want to see your ideas advance, you need to be able to write in a manner that is clear and persuasive.Unfortunately I can’t point you to a text on how to write about technical matters. The best thing I can do is to point you to the archetype of clear, succinct technical writing, The C Programming Language, by Kernighan and Ritchie. This book provides the model every technical writer should use when trying to explain a new technology or concept to technical readers.
You need to be able to work on user interfaces. This is the hardest one
for me, because I have no idea how to arrange pixels on a screen to convey meaning. It drives me nuts every time I try. Given a choice, I will hand off UI design to a trained professional every chance I get. But the fact is, skilled UI designers are exceptionally rare, and a service with a working UI is 100 times more meaningful than some script outputting text on a console. Most engineers will never be able to build beautiful interfaces, but User Interface Design for Programmers by Joel Spolsky is a great beginner’s guide.
You need to know how to think about hard problems in Computer Science. This is a fuzzy concept to describe, but what I really mean to say is, you must read Programming Pearls by Jon Bentley. And when you read it, do the freaking exercises. That’s what really matters. I always pose the same challenge about this book when I speak to undergrads: in the chapter on proving correctness of programs, find the bug in the program that is proven correct.Coming up tomorrow: how to learn everything you need to know about software engineering management.
No comments:
Post a Comment