Skip to main content

Joyous Happy Updates

The Old Goal, Revisited

Quick redirect (more to refresh myself than anyone who is going to read previous posts and then this one without feeling any gap in time--kinda like binge watching an older show on Netflix wondering why the season in 2007/8 was only 1.5 real episodes): This blog was initially created to serve in an alternate timeline where I did not have an internship over the summer. My goal was to develop a web and/or mobile app from scratch, as a way to keep my skills sharp and prepare for graduation in December. This blog was supposed to be a way to document to potential employers "Hey look--I can do the things, even if no one has paid me to yet! And I can write about them, with personality even!"

 So What Changed?

A late but extremely welcome change to this plan was an offer to intern at OrangeBoy, Inc here in Columbus--an exciting small firm that combines a software-as-a-service platform called Savannah with public service consulting expertise to help libraries and similar institutions engage their customers. I should take this moment to expressly state anything you read here, or in any other space in the internet, is my own happy thought that I alone am responsible for and has absolutely nothing to do with OrangeBoy.

So I find it amusing that my last post was on 6/4, the day before I started there. It's been a wild, informative, career-choice-affirming ride that I'm lucky enough to continue through fall semester--but, of course, a job plus school doesn't mean we give up on our side projects. Oh no. Far from it--the job and the homework and all the lessons learned have sharpened the focus and given new purpose to the side projects--an opportunity to build a better clock.

"I am not reading that article--what the hell does building clocks have to do with programming?" -- several readers, probably. 

The short version? Jim Collins explains it thusly:
"Imagine that you met a remarkable person who could look at the sun or the stars and, amazingly, state the exact time and date. Wouldn’t it be even more amazing still if, instead of telling the time, that person built a clock that could tell the time forever, even after he or she were dead and gone?"
Collins uses it to explain business leaders--flashy CEOs with vision to personally drag their company to greatness, but fail to instill that vision in an institutional memory so it will run with or without them. I think it's an even better analogy for software developers.

What do I mean by that? Well...maybe that's better saved for for a new post.

Comments

Popular posts from this blog

Use Cases: The Theory

They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe. I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials . (That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...). At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. ...

Sequence Diagrams: Theorizing

The activity diagram is all well and good, and can even be super useful in a lot of cases. But for my money, so far in my limited experience, the sequence diagram is where you really start to get a handle on what you need to do as a programmer. Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint. The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs. I...

Activity Diagram: Theory

So I've got use cases figured out. Not all of them--only a fool or a genius thinks he can sit at a desk away from the end user and think he's got all the use cases figured out (and a genius would never truly believe it). But you can't sit around trying to anticipate every possible use case before you start, so once we have enough to cobble together a complete program or part of one we can move on for a bit. Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later. Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagra...