It's not been about 9 months that I've been a "real" programmer, working
for an actual boss writing code someone actually uses instead of being a
student or hobbyist, working on classes, research, or a hobby project.
It's been eye-opening: industrial coding is very different from hobby
coding, class coding or research coding.
Class coding involves very small tasks that map almost perfectly onto known algorithmic or computer-scientific problems. You are told to write a Sudoku solver using certain kinds of heuristic searches, and you thus know to write a heuristic search algorithm with a certain set of heuristics and optimizations. When it's done, you just write a tiny bit of code that applies the heuristic search to Sudoku solving. Done.
Research coding can get very involved and very dirty, because it's fundamentally about inventing and/or implementing an entirely new solution to a previously-unsolved problem. It's an act of invention, and if you have to make a publication deadline, you probably won't have the time to make the code look nice. You design the algorithm, you prove it works, and you crank out a quick-and-dirty implementation. Sometimes you also take the opposite approach: quickly-and-dirtily design and implement an algorithm, test it, and see if you can construct a proof that it's a real solution to your problem (I can hear researcher colleagues crying out in pain, but when you don't know if your problem is solvable, this helps you find a solvable case). Either way, you usually only write one algorithm, or a few algorithms, devoted to solving a particular problem about which you definitely know.
Industrial coding, on the other hand, is quite different. It's always very involved and very dirty, but it rarely involves anything of fundamental computational or intellectual difficulty. Instead, its difficulty arises from the sheer quantity of incidental state and details I have to hold in my head to do it. My typical workday, right now, involves opening two iTerm windows with 3 tabs each to run and monitor two Ruby on Rails applications, an iTerm window of one tab to run memcached, two Mac Console windows to read the two applications' debug logs, a Firefox window with at least two tabs to run the apps, and two TextMate windows that each have a tab open for every source file I'm editing at the moment. Count them up: a minimal workflow involves opening a minimum of eight windows with a combined minimum of ten tabs. A more realistic workflow also involves having Apple Mail open and about eight TextMate tabs, for a real total of nine windows and 16 tabs open at once, just to do my day job.
The actual product is just a couple of internal applications for fetching and parsing XML feeds from a content source, then serving the date back up to a user's web browser in JSON form or in HTML Rails views. There is nothing inherently difficult or complex about this. No computer scientist would dare publish a paper about these applications, they'd be laughed out of the research community and told to go back "to industry" from whence they came. Yet actually writing these applications depends on a medley of technologies, domain expertise, experimentation to understand the data formats being sent to us, and intuition to estimate user expectations.
Yet I find this kind of coding much harder than working on research or on a hobby project. My brain has always afflicted me with ADHD tendencies: I get distracted somewhat too easily, unless I'm truly immersed in something, and context-switching has a high cost once I am immersed. I actually find it easier to invent an algorithm for doing type-inference over a Damas-Milner-style type system with subtyping rules than to hold nine windows and 16 tabs of Ruby on Rails data-serving apps in mind at once. I have a much easier time cutting away the impurities from the ore and forging a single, elegant piece of steel than dealing with myriad layers of everyday concrete.
Hence the title: real programming is hard. I don't find it hard in a "fundamental" way, but in a this-is-difficult-for-my-brain way. Hence the title: I have to target myself, for my future, towards the kind of inherently-hard problems I'm actually good at addressing. The funny thing is, I needed at least this minimal time "in industry" to find that out, because before you graduate university, everyone does Computer Science. Only after graduating did I find out that most of my peers have a much easier time doing real, useful industrial programming, while I more greatly enjoy the Computer Science we all fought our way through back in school.
Class coding involves very small tasks that map almost perfectly onto known algorithmic or computer-scientific problems. You are told to write a Sudoku solver using certain kinds of heuristic searches, and you thus know to write a heuristic search algorithm with a certain set of heuristics and optimizations. When it's done, you just write a tiny bit of code that applies the heuristic search to Sudoku solving. Done.
Research coding can get very involved and very dirty, because it's fundamentally about inventing and/or implementing an entirely new solution to a previously-unsolved problem. It's an act of invention, and if you have to make a publication deadline, you probably won't have the time to make the code look nice. You design the algorithm, you prove it works, and you crank out a quick-and-dirty implementation. Sometimes you also take the opposite approach: quickly-and-dirtily design and implement an algorithm, test it, and see if you can construct a proof that it's a real solution to your problem (I can hear researcher colleagues crying out in pain, but when you don't know if your problem is solvable, this helps you find a solvable case). Either way, you usually only write one algorithm, or a few algorithms, devoted to solving a particular problem about which you definitely know.
Industrial coding, on the other hand, is quite different. It's always very involved and very dirty, but it rarely involves anything of fundamental computational or intellectual difficulty. Instead, its difficulty arises from the sheer quantity of incidental state and details I have to hold in my head to do it. My typical workday, right now, involves opening two iTerm windows with 3 tabs each to run and monitor two Ruby on Rails applications, an iTerm window of one tab to run memcached, two Mac Console windows to read the two applications' debug logs, a Firefox window with at least two tabs to run the apps, and two TextMate windows that each have a tab open for every source file I'm editing at the moment. Count them up: a minimal workflow involves opening a minimum of eight windows with a combined minimum of ten tabs. A more realistic workflow also involves having Apple Mail open and about eight TextMate tabs, for a real total of nine windows and 16 tabs open at once, just to do my day job.
The actual product is just a couple of internal applications for fetching and parsing XML feeds from a content source, then serving the date back up to a user's web browser in JSON form or in HTML Rails views. There is nothing inherently difficult or complex about this. No computer scientist would dare publish a paper about these applications, they'd be laughed out of the research community and told to go back "to industry" from whence they came. Yet actually writing these applications depends on a medley of technologies, domain expertise, experimentation to understand the data formats being sent to us, and intuition to estimate user expectations.
Yet I find this kind of coding much harder than working on research or on a hobby project. My brain has always afflicted me with ADHD tendencies: I get distracted somewhat too easily, unless I'm truly immersed in something, and context-switching has a high cost once I am immersed. I actually find it easier to invent an algorithm for doing type-inference over a Damas-Milner-style type system with subtyping rules than to hold nine windows and 16 tabs of Ruby on Rails data-serving apps in mind at once. I have a much easier time cutting away the impurities from the ore and forging a single, elegant piece of steel than dealing with myriad layers of everyday concrete.
Hence the title: real programming is hard. I don't find it hard in a "fundamental" way, but in a this-is-difficult-for-my-brain way. Hence the title: I have to target myself, for my future, towards the kind of inherently-hard problems I'm actually good at addressing. The funny thing is, I needed at least this minimal time "in industry" to find that out, because before you graduate university, everyone does Computer Science. Only after graduating did I find out that most of my peers have a much easier time doing real, useful industrial programming, while I more greatly enjoy the Computer Science we all fought our way through back in school.
0 commentaires:
Enregistrer un commentaire