Top Skills According to LinkedIn

LinkedIn released a list of top skills you should have to get a job in 2016. Unfortunately none of the top 5 looked like anything I was interest in. At least I am studying up in #6 Network and Information Security. That is a long term effort I am undergoing right now. Maybe take another year or two to become proficient. Hopefully the skill will still be desirable then.

The only other skill I am doing a bit in is #10 Java Development. However I am not engaged in that in a hard core manner. It is just that whenever I need a quick and dirty utility, I code it up in Java. Nobody seems to mind that I do that. It keeps me remotely connected to some of the APIs for Java developers.

It is not like I want to chase what is hot now. Because that list if fleeting. But it is nice to see that some activities I am concentrating on are good for my career.

JawaScript Framework of the Week

I recall about 10 years ago I was on a big project. They had a guy that was a JavaScript dude. He was well respected. I figured I should learn the language. Eventually I got around to taking some classes on the subject. Wrote some browser games in JavaScript. Decided it was not necessarily for me.

Today I read a tongue-in-cheek discussion between a JavaScript dude and another developer who has been out of the web development world for a few years. Poor guy. Check out their discussion here.

The take away is that to do anything small these days, you better know what the latest cool frameworks and tools are in JavaScript. The bad news is that there are a lot of them. And they seem to change weekly.

I am all about learning new stuff. But I would like the shelf life of the technology to be much longer than a week or a month. I don't have time for such radical churn.

Comments from the Peanut Gallery

Some time ago my customer gave me a task to complete. There was some trouble getting clear requirements for the task. I did the best I could but went down the wrong path. In the end, my customer hacked an outline for the solution and told me to get it working. I did and we passed it on to another team for integration testing.

Of course the other team found some problems during test. Immediately somebody came out and asked if this stuff was tested. I ignored the comment. Of course it was tested. There was not enough info to diagnose the problem. I asked the other team to run some steps and send back the results.

The results were enlightening. All of a sudden someone else came out and asked the other team to check the data. I abstained from replying. The other team was livid. They were like WTF? I provided another query to get even more info on the specifics of the problem.

By now we had a lot of info on the trouble. My customer dug in and found the problem with his code. This code is pretty complex. It is easy to get lost in it. Harder to pinpoint problems because it is so complex. Now it is time to ship out this fix.

Only thing I have learned is that many people have a lot to say about problems that come up. Most of it is pretty much worthless. I think I have already grown accustomed to the nonsense and I just ignore it.

TortoiseSVN for the new Project

I am on a new project for the time being. Still waiting to get to my eventual destination. The official source code control solution on the project is IBM Rational Clearcase. This is mandated by the customer. However the team informally uses TortoiseSVN to work with files locally until we deliver to the customer.

Personally I had never heard of TortoiseSVN before. It is a client for Apache Subversion source code control. That's where the SVN comes from. It is taking me a while to get familiar with TortoiseSVN. The user interface is presented as an extension to the Windows shell. That is, you right click on thing in Windows Explorer and get TortoiseSVN menus.

Installation of the product is pretty easier. I just went to 64-bit Windows. So I got a 64-bit version of TortoiseSVN installed. Now I just need to figure out the URL of the team's Subversion repository and I should be off to the races.

Staying Current in Technology

Today I registered to take the CompTIA Network+ certification exam. I got about a month and a half left to prepare for it. Currently I am reading a study guide which is not too good. I want to get through it to see if there is anything I can learn from it. Then I move onto a bigger and hopefully better study guide.

This certification is the first on my road to becoming a certified ethical hacker. I want to join a project at work. I talked to some guys on that project. Asked them if there were any credentials that were worthwhile to achieve to get ready to work on their project. They said only the certified ethical hacker.

CompTIA will certify you. But your certification runs out after a few years unless you keep it current. There are a lot of ways to earn credit to keep your certification current. At first I thought this was just a scam to let them make more money off you. That may be true. But the techniques to stay current seem like they are worthwhile.

Here are the things you can do after you earn your certification to qualify to renew it when it expires: get another certification, attend a workshop, publish an article, publish a white paper, write blog posts, write a book, attend a webinar, attend a conference, complete a training course, complete a college course, obtain work experience. There are a few more options such as teaching or creating material for a course.

Those all seem like good ideas to stay current in general. I think I should have no problem keeping this certification current perpetually. Just need to log my progress in learning and I should be good to go.

Cogs in the Machine

This year I think I am finally off the big project I have worked on for the last 15 years. That was quite a run. Now that I have jumped around to a couple teams, I am seeing a different dynamic on the folks that work a project.

When I first joined my long lasting project, there were over 60 people on it. We were broken down into assorted teams. But if you paid attention, you pretty much would know everyone on the whole project. Might not interact directly with each one. But you would at least know them.

After a while, the project downsized a couple times. The steady state seemed to be 40+ people. Upwards of 45 team members. I still knew just about everyone on the team. Then I branched over to a future project that is to be built. Met a lot of people. Did not spend long on the project. But there were many hands. It did not feel like a unified team. I guess maybe because it wasn't.

Now I am on a huge project. There are 250 to 300 people total. I worked once on a project this big. But I knew almost all the people on that prior huge project. This time I just know my team of 7 or 8. We are very compartmentalized. It is kind of weird. Really focused on our specific task in the system.

The jury is not out whether this localized model is better or not. I will find out. Just an observation.

Life as a DBA

I rolled off my old project last year. They seemed to be out of money, at least for me. I did a short stint on an analysis gig. Then that job changed its requirements and I was again looking for work. My manager told me I could return to my old project, but in a different capacity. I would be on the DBA team.

So I reported to the lead DBA. He gave me a task. I hit the ground running and we figured out a problem that plagued the team for over a month. Win. My new team lead was going on a long vacation. He put me in charge of a database task. I was ready to make some progress.

Turns out I don't have the privileges to do the things I need to do in the development database. There are some other DBAs that handle that. Okay. I did some prep work for testing. Then I scheduled up a meeting with the DBAs in charge. We went nowhere fast. They apparently would run scripts on our behalf. Ok...

I had another developer write up some scripts. The DBA pulled it up onto the UNIX box and he kept getting Korn shell errors. The file was there. Ksh kept complaining that it could not find the file. I left the DBA to figure out the details. Turns out he uploaded the file in the wrong mode. The lines were terminated incorrectly. Doh.

I decided to take a look at the script files. The author put a tar file on the UNIX box. I grabbed a copy and tried to extract the files. He gave me instructions to extra via a tar -cvf. I tried a couple times. Tar kept giving me errors. This seemed like deja vu. Luckily I stepped back and read up on how tar works. Turns out that command was similar to the compression. I needed a tar -xvf. And I was off to the races.