Disclaimer and License

Opinions expressed here by Tim Tripcony are his own and not representative of his employer.

Creative Commons License
Tip of the Iceberg is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at timtripcony.com.

Unless otherwise explicitly specified, all code samples and downloads are copyright Tim Tripcony and licensed under Apache License 2.0.

Search

« I finally know what a component's "binding" property is for | Main| XPages vs. Flex - a point by point comparison »

"Do I Need to Learn Java?": a brief conversation with a composite character

Category java
Do I need to learn Java?

To sustain life, one must rather frequently breathe, eat, drink, sleep, and excrete. Everything else is optional.

No need to get sarcastic.

I'm not. That's the truth. Almost everything we do is superficial, designed to make life comfortable, convenient, entertaining, and fulfilling. But everything we do beyond attending to raw survival is optional; it serves only to further our pursuit of what we assume will be more pleasant than a lack thereof.

So... um... I don't need to learn Java? I though you said I did.

Then I apologize for miscommunicating.

It's okay, maybe I just misunderstood. Should I learn Java?

It depends.

On what?

First and foremost — really, beyond any other consideration — it depends on the size of your team. If you are the team, then yes. You should learn a little bit of Java, a little bit of JavaScript, a little bit of CSS, and a lot about the many frameworks out there that allow you to write as little of each as possible while delivering something visually and functionally elegant to your customers. If you're writing tens of thousands of lines of code — in any language — it's quite possible that you're reinventing a wheel in there somewhere... duplicating the efforts of some very smart people you've never met.

If your team typically contains at least one other person, examine your strengths and preferences. It's very liberating to have at least one person who can focus only on what the app looks like and at least one person who can focus only on how it works behind the scenes. When each person can be doing the work that feels most instinctive — and, yes, even fun — to them, end users' needs can be met in a fashion that delights them without those responsible for delivery devaluing each other for not necessarily being quite as passionate about one specific facet of the end-to-end solution as another might.

But, again, if it's all up to you, then strike a balance. The "right" code is rarely the "ideal" code: it's the code that meets the needs given whatever constraints are in play. And being the only one responsible for delivering the entire solution is a rather significant constraint, because it's up to you to make sure that you're not devaluing any aspect of that solution — security, reliability, performance, scalability, accessibilty, or the overall experience your users ultimately have using the app. Each of those elements is crucial, and the more languages — and frameworks — you have obtained a comfort level with, the more easily you can ensure you're placing sufficient emphasis on each.

Sounds like I still have a lot to learn. That seems kind of daunting.

I know, right? Isn't that awesome? I've been doing this stuff for just over 16 years, and rarely a day goes by that I don't encounter something that makes me feel like a novice again. I'm constantly reminded how lucky I am to have found a career that's always fresh and new, constantly changing, constantly evolving. Some of the alternatives I'd considered when I was younger are comparatively static: once you learn how to do it, you're done learning. You just do the same thing over and over again, day after day, year after year. How boring. Isn't it awesome that the moment we're tempted to think we're experts at what we do, something new comes along and we get to discover that too? And people actually pay us to keep learning?

When you put it that way, it does sound more exciting than scary.

Good. That's how it should be. Or rather, how it really is. It's sort of instinctive, even for those of us who love learning new things, to assume that learning something new is a scary thing. For me right now, it's Scala. I'm honestly a little freaked out about wrapping my head around that language. I remember going cliff-diving with some friends a long time ago in Colorado. I stood on the edge looking down at the water, my heart pounding. Then I jumped, and the fear turned to exhilaration. I climbed out of the water and ran back to the top. And immediately the fear came back... but this time it was mixed with the memory of the exhilaration. I know it's a bit corny to be comparing cliff-diving or skydiving — or anything else that seems scarier than it is until you actually do it — to learning a new programming language, but it's not entirely dissimilar.

I guess I just have one remaining obstacle: my job is so demanding, it feels like I don't have time to learn all of these technologies at once. They want everything done yesterday, so it's hard to learn on the job, and they never approve any training requests, so anything I learn, I have to teach myself... and my employer doesn't really provide any incentives for me to even bother.

All the more reason to be able to list competency in these technologies on your resume without lying. Software development is an enormous industry. It's unlikely to shrink in the foreseeable future. While the prevalence of various programming languages differs based on who you ask, nearly every recently published analysis places both Java and JavaScript fairly close to the top of the list. The more solid your comfort level with either — but preferably both — the more likely it is that you can find a better job where you're rewarded financially and otherwise for your skills and passion. You may have to occasionally forgo watching your favorite crime drama or sporting event in favor of online tutorials in order to spend a few evening or weekend hours each week gaining confidence in these languages, but imagine how much more relaxed all your evenings and weekends will be by comparison once you're no longer spending at least 23.8% of each week being systematically devalued by your employer.

If that sounds appealing to you, then I'd urge you to specifically examine mobile technologies. Domino may be around forever. It might not. Mobile isn't going anywhere. This technology has truly arrrived, and now that it has, the consumer market will not let it leave. The emergence of "wearables" is one of the latest indications of how the underlying technology might evolve and where else it might spread, but that underlying technology is not going to just disappear. While toolkits abound for writing mobile apps in JavaScript and then compiling them into platform-specific containers, end users can tell the difference, even if they aren't conscious of what they're sensing. The "experts" agree: the best mobile apps target each platform separately, and are written in the native language of each platform. For iOS, that's Objective C. For Android it's (melodramatic drum roll) Java.

So here's just one of many possible ways you could get a job that rocks: watch this awesome video tutorial on Android development. It consists of 41 separate segments totalling 13 hours, but the last 9 (roughly 2.5 hours) are specific to the Samsung SDKs, so by all means, feel free to watch those too... but at a minimum spend 10 hours watching everything up to that point. If you can set aside one hour each weeknight for this, you're finished in two weeks. You won't be an expert on Android development by the end of those two weeks, obviously. But if native mobile development has ever seemed scary to you (like it did to me this time last year), it won't any more. And maybe you'll be really excited about it... maybe enough to spend a few hours a week building experimental apps. And maybe after 6 months of that, you'll feel confident enough in your grasp of the platform to tell your current employer to go......... easy on whoever they hire to replace you because you're leaving to join the Android development team at some exciting new startup. And maybe you'll create the next MySpace / Twitter / Facebook — MyTwitFace, perhaps — and can spend the rest of your life hiking the Alps or drinking cocktails with umbrellas somewhere in the Caribbean.

Or maybe the comfort level you acquired with Java while experimenting in your free time with native mobile development makes it easier to identify ways to occasionally apply a few of the same principles in your XPages, and maybe over time that simplifies your process enough to where your job feels just a little bit less demanding than it used to. And maybe that's enough.

Either way, that's probably worth committing yourself to an initial 10 hour investment... right?

Comments

Gravatar Image1 - Excellent post Tim. I like ploutering (Scots for tinkering without really having a target in mind - it's easier in Scots, unless of course I have to explain it Emoticon )with Computers and getting them to do what I want. I have been asking myself this (should I learn X insert programming language du jour here) on amd off for about the last 15 or so years. This is the best summation I have seen in a while and I seem to remember the last time I read something similar that you wrote that too. I'm away to send it to my son who is just starting out in Computing Science.

Gravatar Image2 - Great post! I absolutely agree with you that the decision should be based on your situation and what you and your business can sustain. I appreciate your comments on making the time to learn new technologies. One of the benefits of my job is that no two days are alike, so its up to me to make sure I am learning something new every day.