Leveling up as a developer!

It’s satisfying adding a bunch of IBM acronyms to my “marketable skills.” They’re not that intimidating after all!

I spent the morning and part of the afternoon pair-programming with Bharat Boddu on a time-sensitive project involving an IBM software stack. It was a struggle in the beginning. Both of us were new to all of this, and the sheer volume of information available for Rational Software Architect, Websphere Application Server, DB2, and other parts of the stack was overwhelming. The simplest of things tripped us up because we didn’t know how to debug them. For example, we learned the hard way that adding the DB2 classes to the project’s classpath didn’t mean that they were part of the runtime configuration classpath when the web services were deployed to the server. I also spent what seemed like an hour trying to deal with this issue from the web service explorer:

IWAB0135E An unexpected error has occurred. 
302 
Found 

(Solution: Check the endpoints you’ve defined in your WSDL, or define new ones. example.org won’t work.)

Once we got over those roadblocks, things flowed smoothly. We used Rational Software Architect to define web services, deployed them on Websphere Application Server, and queried a DB2 database. We also figured out how to work with complex data types and lists for both input and output. We needed to figure out how to consume web services too, so I dug around until I found a web service defined by a WSDL that played well with our configuration. All these bits and pieces will come in handy when we start working on the real requirements.

I can feel myself learning all sorts of new things. I love these moments: the magic of concepts snapping together, like the way you reach out and find things right where you’re looking for them. And I’m slowly inching my way into another area of developer awesomeness: dealing with middleware, service-oriented architecture, and all sorts of other business-y things.

Here’s what I do well, and what I’m learning to do even better.

  • I’m good at breaking down tasks or ideas into small chunks that I can work on or test. This is really helpful when learning something new, because it helps me gain skills and confidence. It’s challenging when I can’t get enough of a grip on something to figure out what a good first task is, or sometimes what the intermediate tasks are, but once I get the hang of the internal logic of something, I can go pretty quickly. I’m getting even better at this by learning about more platforms and toolkits, and by learning bigger “chunks”.
  • Similarly, I’m good at breaking down unknown quantities and figuring out how to test parts of them. I can apply the problem-decomposition skill I use in development to estimating and planning, too. The book I recently read (How to Measure Anything) had great tips on how to strategically reduce uncertainty; reading that gave me a way to recognize what I’m doing and to improve that. So, for example, I can start with an estimate with a wide range, and I can break it down into the risky parts and some ideas on how to get a better understanding of the numbers.
  • I’m getting better at quickly prototyping applications. It’s fun taking a simple idea from a whiteboard sketch to a mostly-working prototype in a day. =D
  • I’m doing surprisingly well at juggling multiple projects. I’ve got two projects that are time-sensitive, and we seem to be doing okay. There are several projects in the pipeline that I’m working on, too. I keep personal notes on what’s on my radar and what I need to do, and I’m good at keeping folks up to date. I can get even better at this by spending more time to communication and planning, and possibly setting up some filtering rules for my inbox.

I’m glad my manager took a chance on these projects, even though I did have to work through looming panic. ;) (It gets much easier to deal with intimidating systems when you get going!)

This is good. I like this feeling. And I can still fit in sleep, presentations, blog posts, homework help, and sanity breaks. =) Hmm…

2011-03-09 Wed 16:51

  • http://www.trajano.net/ Archimedes Trajano

    Just a small tip when doing web services based on 6 months of actual real experience (yup I know very short ^_^)

    Try to do it by hand.

    Even a simple hello world example and get it deployed. I find that it helps when diagnosing the bigger problems.

    Use different stacks

    Although you may be targeting WebSphere in the end, the nice part about working in Java/WSDL/XML is things tend to be standardized. I usually develop on Glassfish (in the end that’s what I settled down from Geronimo/Jetty/Tomcat/CXF/Spring over a weekend). By looking at a smaller development stack which can run on weaker machines with more speed, it gets me to see how things work more easily.

    Then I just deploy and find out what non-standard way of things the target product is doing (e.g. WebSphere requires special deployment steps to deploy EJB based web services such as adding a router web app).

    If you look things through the point of view of a CS guy, Web Services are nothing more than RMI with more standards around it. The architectural/business guy would see it to be a lot more than that, but the typical CS guy could just reduce things down to that level. I debug/implement things as a CS guy, that way I won’t have to think as much.

    Designing and architect a web service is another thing though, but at that level you don’t think of IWAB0135E errors.

    One other experience point, I’ve had to deal with systems where the only message I got was “Internal Error”. So it is best that you have other (simpler) targets to do your work on so you can prove it is not your code but something else. Or if you’re lucky you’d find out it was YOUR problem so YOU can fix it. Somebody Else’s Problem (SEPs) are much harder to fix.

  • http://sachachua.com Sacha Chua

    Rational Software Architect works decently well on my computer, actually, so I haven’t needed to look for an alternative stack. So far, we’re doing okay. =) Thanks for the tips!