Thursday, November 10, 2011
TechPoint Innovation Summit Overview
Ball State had a series of booths at the TechPoint Innovation Summit to showcase some technologies and student-led projects. Morgan's Raid was featured, and I and another student involved in the game's development were there to answer any questions passerbys might have.
Overall, we received a lot of positive feedback. Those people who stopped were interested and impressed (or at least they pretended to be) with our work. Even the fellow Ball State-related individuals seemed impressed and could understand how much work went into it.
The crowd at the event was overwhelmingly business-folk, which was perfectly fine. Not everyone was interested in our work, which is understandable. I am, however, glad that I took some advice from someone and suited up. There were plenty of potential employers on-hand, and I would rather err on the side of business attire than on casual, but I'll talk more on potential employers in a moment.
My colleague and I didn't get a chance to hear many of the talks/presentations other than the one directly after lunch (speaking of lunch - it was fantastic!). We were pretty busy chatting with the folk that came by our booth.
As far as potential employers, there were the expected Indianapolis companies, Interactive Intelligence, ExactTarget, etc. Anacore had their Synthesis technology on-hand, and the demonstration was impressive. It looked very fluid, very easy to use.
There were plenty of other companies that my partner in crime and I spoke with, and I'm glad that I went. Even if I don't land a job from any of my leads, getting out there and speaking to professionals is a worthwhile experience. It definitely eased some of my anxieties, and I'm thankful to be entering into a field that appears to be very healthy, despite an uncertain business world.
Saturday, November 5, 2011
Whirlwind
It seems I have reached the point in the semester in which everything comes due and everything occurs. Hopefully I've navigated it well enough to get through this semester with all of my hair. Time will tell.
I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.
The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.
My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.
The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.
Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.
I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!
I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!
I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.
The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.
My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.
The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.
Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.
I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!
I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!
Saturday, October 1, 2011
My Review of 97 Things Every Programmer Should Know
A month or so ago, my wife and I were glancing through the local library. I, naturally, gravitated toward the tech section to see what they had to offer. There were some behemoth books, including Java In a Nutshell, which appeared to be about 8 inches in diameter.
I continued to work my way through the iOS books, the For Dummies titles, until a small, purple colored book caught my eye. The book was titled 97 Things Every Programmer Should Know. It's billed as the "Collective Wisdom from the Experts", and I found that to generally be true.
The book is arranged in very tiny gulps. Each topic has a separate author and spans all of 2 pages. It's a very approachable read, and it's one that you can safely pick up for 20 minutes and set down for a week.
The concepts are mid-range, technology-wise. You'll get a few code examples and references to specific hardware/software, but I never felt that the concepts were far over my head.
The authors seem to be experts or, at the very least, professionals with years of experience. The only one I recognized by name was Robert Martin. Over the duration of each article, I grew to trust each author's advice.
Generally, I knew 90% of what I read, which probably suggests good things about me. The big thing that I'll take away from this book is the idea of thinking of the opposite side of the work equation when I'm coding. Meaning I should try to think of the user, the tester, the manager when I'm working. I don't have a lot of experience with Quality Assurance testers, but I understand their role and I'm better equipped to work with them having read this.
Another concept that came up in a few different ways was to continue learning. Several of the authors recommended learning new programming languages regularly, reading the humanities, or learning other spoken languages. Communication is obviously pivotal when it comes to programming, and the advice in this book made that much very clear.
In the nugget "Pair Program and Feel the Flow" I enjoyed this particular part:
(By Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland)
Robert Martin had this insight to share:
Here are a few of the topics that I found interesting, but in consideration for keeping this short, I'll just link directly to them:
Comment Only What the Code Cannot Say by Kevlin Henney
Continuous Learning by Clint Shank
Learn to Say "Hello, World" by Thomas Guest
Read Code by Karianne Berg
Ubuntu Coding for Your Friends by Aslam Khan
WET Dilutes Performance Bottlenecks by Kirk Pepperdine
And a list of all of the contributions in the book:
Overall, I enjoyed the book. I took a while to read through it since I had a lot of things going on, but the book is cut up into small enough portions that anyone could read for 10 minutes and get something out of it. I'd especially recommend it to junior or senior undergrads. There were a lot of great concepts, but even if the reader knew them beforehand (as I mostly did) the book serves as a great motivator.
I continued to work my way through the iOS books, the For Dummies titles, until a small, purple colored book caught my eye. The book was titled 97 Things Every Programmer Should Know. It's billed as the "Collective Wisdom from the Experts", and I found that to generally be true.
The book is arranged in very tiny gulps. Each topic has a separate author and spans all of 2 pages. It's a very approachable read, and it's one that you can safely pick up for 20 minutes and set down for a week.
The concepts are mid-range, technology-wise. You'll get a few code examples and references to specific hardware/software, but I never felt that the concepts were far over my head.
The authors seem to be experts or, at the very least, professionals with years of experience. The only one I recognized by name was Robert Martin. Over the duration of each article, I grew to trust each author's advice.
Generally, I knew 90% of what I read, which probably suggests good things about me. The big thing that I'll take away from this book is the idea of thinking of the opposite side of the work equation when I'm coding. Meaning I should try to think of the user, the tester, the manager when I'm working. I don't have a lot of experience with Quality Assurance testers, but I understand their role and I'm better equipped to work with them having read this.
Another concept that came up in a few different ways was to continue learning. Several of the authors recommended learning new programming languages regularly, reading the humanities, or learning other spoken languages. Communication is obviously pivotal when it comes to programming, and the advice in this book made that much very clear.
In the nugget "Pair Program and Feel the Flow" I enjoyed this particular part:
(By Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland)
Reduce the "truck factor": It's a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members? Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can complete the work. Your team's flow is not as affected by the "truck factor."
Robert Martin had this insight to share:
What is a professional programmer?
The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.
- If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job.
- Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to findnothing because they don't release their code until they've thoroughly tested it. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find.
- Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover.
- Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.
- Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?
Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.
Here are a few of the topics that I found interesting, but in consideration for keeping this short, I'll just link directly to them:
Comment Only What the Code Cannot Say by Kevlin Henney
Continuous Learning by Clint Shank
Learn to Say "Hello, World" by Thomas Guest
Read Code by Karianne Berg
Ubuntu Coding for Your Friends by Aslam Khan
WET Dilutes Performance Bottlenecks by Kirk Pepperdine
And a list of all of the contributions in the book:
Overall, I enjoyed the book. I took a while to read through it since I had a lot of things going on, but the book is cut up into small enough portions that anyone could read for 10 minutes and get something out of it. I'd especially recommend it to junior or senior undergrads. There were a lot of great concepts, but even if the reader knew them beforehand (as I mostly did) the book serves as a great motivator.
Subscribe to:
Posts (Atom)