The Reach of Marketing - I love a good original chicken sandwich at Burger King. That's why I head there when I get a coupon from them that sweetens the deal. I might get a free f...
All things Java seemed up there on the list. You should learn Hibernate. Know your JSPs. Even old school Java technologies such as JDBC can help you get a good salary. And of course app servers like jBoss can give you a kick up in pay.
I am hearing more and more about DevOps. Not quite sure I get it yet. But knowing Puppet, Chef, and Jenkins can put you in the running for a lucrative career.
Then there is the Hadoop corner. I don't know all the details. But good buzzwords are Hive, Pig, and Hbase. Heck. Even the base technology of MapReduce is still a desired one by employers paying the big bucks.
Finally there is the noSQL camp. Turns out Cassandra is one of the hottest implementations of a noSQL database out there. Hot trends are always changing. But it is good to try to learn a thing or two in the hot sector.
It was a bit funny but sad too. How meticulous can you be if you cannot spell meticulous? At least run your resume through a spell checker and correct the problems before blasting your resume out to strangers. Otherwise you will face peril.
I took a closer look at the resume. Seems like the guy is going to college to get his degree. Not sure how my company hired him. I tried to get a rock star college student hired. Was told that we only hire college grads from good colleges here. Go figure.
Well replacement might be the wrong name. They hired new middle managers and called them the delivery management team. Now the senior managers sit back and let the middle managers handle all the muck. We have a lot of middle managers working hard.
My own team has been dwindling down due to attrition and reassignment of team members to other initiatives. We each have more responsibility. Oh well. My team is now small. I took a vacation last week. When I came back, the team lead had also taken some time off.
The delivery manager in charge of us seems to have a plan of his own. He wants to delegate down to the team leaders. And when my team lead is out, I guess the buck stops with me. Now doing management by itself might not be evil. But I don't want to manage when I also need to turn around and do most of the actual work.
I call shennanigans. Definitely don't want to end up doing a middle manager's job. Not at all.
Ha ha. That's going to be my new methodology. OOPS. Just have to come with a catchy algorithm and run with it. Heck it sounds close enough to OOP that I might just be onto something.
Metadata to the rescue. I could store all the info about the tables and columns in a metadata store. Then a query builder could interrogate the metadata and build up my SQL strings on the fly. Maintenance of the metadata will be a whole lot easier than going through all the hard coded SQL.
Had a manager call me up today to discuss my proposal. He tried to drill down into the structure of the metadata. Unfortunately he did not fully understand the problem being solved. He also pitched a very verbose metadata structure. I want my job to be a whole lot easier. Don’t want to shift all the hard work from code changing to metadata maintenance. Got to formulate a plan to get him to see things my way.
I told him the thing to do would be to activate some logging so he could build a bread crumb trail. That way he could figure out what was going on in the stored procedures. I call this the old printf style of debugging. So we sprinked some logging to a database table in his routines. Then we ran the code again.
Sure enough, some output was generated in the database table. We traced it down to the code he wrote. Then we iterated and added more logging in the local area where he thought the code was not working. All of a sudden, the application started working correctly. Wait what? I could not imagine just adding logging would fix the problem.
I gave it some thought. The logging did not magically fix his code. He was just not running the same version of the code that he was looking at. He just assumed that the version of code he worked on was what was deployed. Next time I should have him extract the source code of the stored procedures right out of the database. That would prevent this surprise.
Turns out my normal backup was also out of the office. That's okay. I trained the new guy on this system. Unfortuantely he told the managers that he knew nothing about the operations. Fail. I guess I trained him up but he did not use that knowledge. So he forgot it all.
Today I was scheduled to give a one hour session on the system. I did so. Took around 30 minutes to give a high level overview plus a hands on demonstration on how all the pieces get run. Then a manager asked me to prep the audience to respond to problems. Another manager asked that I give them the steps to "reset the data".
Unfortunately the only way to get familiar with the system is to get your hands dirty. You got to resolve a bunch of trouble tickets. Only then will you get the chance to dig deep and understand what the heck is going on. That's how I learned. That's how my backup learned. And that's how everyone else is going to need to learn. Sorry. Once again there is no silver bullet here.