Sunday, April 20, 2014

Lift Turn Brake

Yeah, so, I went to rally school.  It was fucking awesome.  And it is amazing how a person can have driven so many thousands of miles while being so incredibly ignorant about how cars work.  For example, did you know that it is possible to literally steer with the brakes and not the steering wheel?  I was holding the wheel at a fixed position, but the car was going left or right based on what I did to the brake pedal.  It was surreal.

I could go over the events of the day and embellish things in the write the time I was so bad in an exercise my instructor made me do it an extra 3 or 4 times while the entire class watched, however despite how awesome the experience was it would probably make a boring story.

I got some good pics to make my life looking exciting to NSA spooks and random acquaintances on facebook.  I also got a GoPro video of my performance on the last exercise, however my performance was absolutely abysmal.  There were a few turns that I did correctly, however even they don't look good from that camera position.  So no one is gonna see that footage unless we edit in some european rally cross.

If any one asks, though, I did awesome.  And we had a race at the end.  And I won.  And also Jennifer Morrison and Jenna Coleman were there.

Thursday, April 17, 2014

[coding] How to Code Review People You Like

People who visibly save thousands of dollars are rewarded better than those to silently prevent the loss of millions

I originally wrote this as an answer to a question on a reddit thread, and then realize that the poster (or "OP" in reddit lingo) probably has no interest in reading it.  So, I'll leave it for you guys!

In a software company, a Code Review is a development practice that can make one or both participants look good, or bad, and can be used to slow down a check in.  Sometimes people also find programming flaws.

Your true motivations in a code review can very widely.  Maybe you need to subtly delay a co-worker's check in so that you don't have to deal with an inevitably ugly merge.  Maybe you need to make a show about due diligence while  stealthily introducing a "feature" that is going to make another team's on-call really unhappy in about 12 hours.  Maybe you are code reviewing a friend and you want to make him look good.  Maybe you are code reviewing an enemy and need to make him look bad.  Maybe you are code reviewing an enemy that thinks you guys are friends, and you need to make him look bad without him realizing it.  Maybe you need to code review an idiot, but in such a way as to cause him to accidentally learn something without bruising his ego.  Maybe you need to bait someone into giving you a positive or negative story for peer review time.  Maybe you want your team to lose face.  Maybe you are taking salvos in a religious war about code style, or a religious war about SOA frameworks, or a religious war over configuration, or a religious war with some dumbass principle in another org, or a religious war about some dumbass thing a guy wrote before being promoted off to VP where he can't do as much damage.  Maybe you have your own agenda you are trying to push, because if everyone stops doing this 1 stupid thing, you can decrease your servers in production by about 80% (remember:  people who visibly save thousands of dollars are rewarded better than those to silently prevent the loss of millions).  Maybe you need to make sure there are no bugs or other flaws in the system because you are on call next week.

I'm going to assume that you like these guys, and you have no interest in harming their careers, or making them or their team look bad.  I'll also assume that you have no styling agendas you need to push, and there is no bad blood between your teams.  If any of those assumptions are wrong, stop reading, because you would need a completely different strategy.

If that's all true, then you're job closely aligns with the original intent of the CR:  to improve code quality.  That's the benefit of CRs.  The cost is time.  CRs are not magic, and they are not free.

Every good suggestion you make saves time and money (especially if you prevent bugs going to production).  Every dumb suggestion you make wastes time--time spent arguing with you, time spent recoding, time spent retesting, time spent on CR #2.  It can also cost you social or political standing.  Since you have no interest in embarrassing these guys, or slowing down their checkin, you want to be careful not to make any dumb suggestions.

Based on the tone of your question, it sounds like you are unfamiliar with any standard style guidelines at your company.  You should find out if there are style guidelines for the project.  If there aren't, DO NOT make style suggestions (I'm assuming you dont want them to hate you), except in cases of extreme stupidity.  If there are, you might get away with selectively nitpicking the ones you care about.  If you have your own personal style religion, advance it at your own risk.

Next is the design.  In general, Java devs usually have a hard on for over-designing things that will never change, while ignoring things that are about to.  Interns that have just taken a "software design" course will probably be even worse.  Keep a look out for any major flaws, however restrict your comments to things that are both obvious and easy to explain.

Next, look for dumb mistakes.  The tone of your comment should convey a belief that these guys are smart and it was a slip of the keyboard, even if they are idiots (especially if they are idiots).

Next, look for things that are unclear.  If they do anything weird, they need to add a comment, and that comment needs to answer the question WHY.  Most idiot programmers add comments that answer the questions WHAT or HOW, and then get all pissy about being forced to write comments.  However if its a small check in, and they dont need to change any code, and you're not trying to slow them down, it is probably not worth it to ask them to write comments--unless you also tell them that you don't need another CR iteration before they check in (by the way, the 'I don't need to look at it again' thing is how we...nevermind).

You need to review your own comments.  If this is more than a few lines of code, and it is a public CR (i.e. the whole team, or your boss, or the whole org is going to see) you need to make sure you look like you've given a good review--most of the HR "career management" bullshit about what a great developer is at places like Amazon/Netflix/Microsoft/whatever is tied to people (all people, including idiots) thinking you give good CRs.  Go through the code again, and make sure you nitpick according to the beliefs of anyone important that might see your review.  Are we supposed to hate ThreadLocals?  Bust on them for using thread locals.  Are we supposed to love ThreadLocals?  Find a volatile variable and and ask them it should really be a thread local.  Does the Principle dev hate ThreadLocals while your own manager loves them?   Do whatever it takes to make sure that all of the people with political power think that you have the same beliefs they do.

Also, with most corrections, if you are not blindly reciting things, it is always better to ask, because you still look like you believe all the right things, while they are still held accountable for their answer.  If anything goes wrong, you can say you had to "disagree and commit" or whatever the appropriate corporate lingo is.

You know, this makes me wonder if you could make a sort of "House of Cards" with programmers.

For more information on code reviews, programming style, and working for a large corporation, please see this guide on software development career management.

Friday, April 11, 2014

The Event Horizon of Human Knowledge

Watching some new TV show about what we know about the universe, and it got me thinking:  the more we know about science, the longer it takes each new person to go to school and re-learn the the things that humanity has already discovered before he can go off and add something new to the pile.  It is possible that one day we will have accumulated so much knowledge that individual people can no longer learn enough in there lifetime before making their own contribution?

If such a horizon exists, it is probably far in the future, because of the enormous disparity between how long it takes to discover something, and how long it takes to learn it with the right teaching aids (e.g. how many PHD-hours did it take for general relativity vs how long for a student to learn it, especially since all students can learn in parallel?

One obvious solution that we already employ is specialization.  Neurosurgeon vs denstist, etc.

Also, my premise could be wrong.

Also, advances in medical technology could result in us living longer, sufficient enough to keep pace with our own body of knowledge.

It might make an interesting Sci Fi plot though.

Thursday, April 10, 2014

[coding] The Entire Java Community vs URL Encoding

I am broadcasting this because it is hilarious and sad.  Try this:  pretend you have a fragment of a URL...i.e. the query string, and you need the query string encoded.  Also, there is this thing called "url encoding" that is done with an html form.......and that's a different algorithm.  You want url encoding ... not  ... url encoding.

There must be a standard (i.e. NOT spring), not-deprecated java library somewhere that provides a static encoding method...right?

Sunday, April 6, 2014

Day 54

Today was a good coding day.  Yesterday I hardly got any work done, however today I got so much work done that I sort of caught up to where I hoped to be.  Why did I do so much better today?  It wasn't extra caffeine:  I only had one soda, two coffees and one energy drink all day.  Trust me, that is significantly below average.  My hands aren't even shaking.  Although I have accidentally stayed up until 5 am.

So.  If it wasn't the caffeine, why did I get more work done today, especially after a morale-busting 3 day slump?  The only noticeable things I changed are:
  • no TV
  • no errands beyond food/coffee runs (no bicycling, going to the store, hanging with friends, nothing) 
  • no music

The lack of music element is interesting.  Normally, I play Epic Music.  And by Epic, I mean that literally.  Like most of the songs are from soundtracks for movie trailers and, well, movies.  For example one of them was used as background music in an episode of Top Gear that features a fighter jet chasing super cars.  The artist that makes the bulk of the stuff I like is called Two Steps from Hell.  Its the only music that does justice to the magic I work with a keyboard, and unfortunately, I've listened to it so often, over and over again, that it is ruining my concentration.  All 20 hours of it.  I've heard of people having trouble concentrating while listening to music.  The lack of words was supposed to mitigate that.  It would seem, though, that listening to the songs until I am sick of them is also distracting.  Or, perhaps, listening to any music at all is distracting.

Today?  Mostly silence.  And I got a shit ton of work done.  I suppose I will experiment with Silence some more.  Actual silence though, as opposed to the hit single Silence by Delirium which is basically the best song every created by humans.

I would be happy to share my playlist, but I don't want to post the link in such a public place;  still scared from having YouTube ask me over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and wait did it stop? no...and over and over and over and over and over and over and over and over again if I want to use my real name.


The lack of TV...this one is also perplexing.  I thought I had some good experiences with TV shows and/or movies giving my mind a break, allowing me to return to coding faster.  However, watching TV may also harm my attention span, making it harder to maintain concentration.  So it could possibly be providing short term gains at the cost of a medium term detriment.  I don't know.  Shit, man, I was supposed to be in San Francisco this weekend...forgot to buy a plane ticket until the day before though, and then they were too expensive.


Time evaporates beneath my feet, like sand in an hourglass.  It feels like I just returned from my trip to New York City a few days ago, however according to my Wall of Progress, where I write down my daily accomplishments, its been nearly thirty days since I got back:

I don't quite have as much to show for it as I'd like.  That scary blue post-it note on the right is the physical position of the notecard I'll be placing after the last day I am able to work on the project. actually right about the time I'll have to take all that down and move out.

The loneliness is kind of driving me crazy.  However, at the rate that I perceive the passage of time these days...this entire adventure is going to be over in the blink of an eye.

Tuesday, April 1, 2014

A Confession

I've spent a long time thinking about it, and I'm going to have to just come out and say it.  Some of you may have suspected.  The clues were all there or whatever.  Like my joke about how I identify as a woman on Wednesdays.  Its not just Wednesdays, guys.  Its every day.  I've known, and hid this, my whole life...ever since I volunteered to play barbies with my sister because she had a barbie van that could transform into a house (growing up we had neither cable tv, nor any transformers toys).  But it just felt so right.  Ever since then I've selectively believed or discounted all evidence based on whether or not it supports the conclusion that I already know to be true.

I can't live my life as a man anymore.  I'm going to start taking hormones and get my balls cut off.  The next time you see me I'll be wearing a dress, and I'll be super insecure about myself and I expect everyone to play along with me being a woman.  I still only like girls though, so I'm a lesbian, which makes it totally ok with me not wanting to dance with, or really touch, other men, and I can finally get away with it.

Wow that's a load off my chest.  I am so happy to finally be free.  I'm afraid this entire blog has been a total sham, a failed experiment in being someone I'm not.  In fact, as a feminist, the content here is repulsive, and obviously all of you are automatically racist, sexist misogynists for reading it.  This will be my last post.  If you are a tolerant, fat positive atheist with all of the right political views you may continue to follow the exciting adventure that is my life on my new tumblr, PlasticDiamondsAndLipSyncing.  To the rest of you shitlords, I say, fuck off.

p.s. I actually an otherkin.  I identify as a fox.

Thursday, March 27, 2014

Day 43 of 74 (Previously 84)

By calendar time, this little coding adventure is more than half over.  That is largely because of my trip to NYC.  The trip itself, plus all of the personal errands I had to do before and afterwards, cost me  14 days.  Worth it, I supposed, since I did manage to find a place to live.  On the tail end of this thing, I've calculated that I will probably lose 10 days to the move, since I didn't take that account when I came up with my estimated amount of time.

Work continues to go slower than I'd like.  When I first began this I thought I had a real shot of getting this feature complete in 84 days.  I...under estimated the amount of work.  By a long shot.

Now, as far as my performance goes, I have noticed the following two things provide the most benefit, by far:

1.  caffeine
2.  not working on the stupid fucking database

Caffeine is an incredible, performance enhancing drug for the programmer.  It's not good for you...not in the amounts that I'm using.  But it sure as hell gets me going.  I can plow right through distractions, tangential but pre-requisite tasks, tech debt, design decisions...anything.  The obvious downside are there, of course...tachycardia, sleep impairment, nighttime and daytime teeth grinding, a sort of global jittery feeling and the sugar is sabatoging my efforts to get in shape.  However...the amount of work I can get done makes it worth it in the short run.

Not working on the stupid fucking database...I don't know what happened.  All of the sudden, I just can't stand dealing with relational databases.  There's nothing inherently wrong with them--when you have a relational problem you need a relational storage layer--but I just don't like them.  Everything is a giant fucking chore.  You have to mess with the schema.  You have to--sometimes--create a stored procedure to protected the schema.  You have to use a database access library in your language of choice, and database access layers are a fucking field day for people who enjoy over-designing things.  The greater majority of the times I stop work and start procrastinating are because I realized I have to deal with one of the database layers.

In other news, I sold my TV and while I did buy a ridiculously expensive projector, I haven't really felt like using it yet.  So possibly the lack of TV watching is also making me get more work done.

Also, I am currently vetting two more android coders.  I found them by posting a small teaser project to craigslist.  Learning from my experience last time, I chose not to reveal my personal expectations of what a programmer should be capable of, and left the price open ended.  I got about 20 responses, and two of them weren't idiots.

I haven't let them touch the main codebase yet, but I have had them prototype some of the features on the back log.  Given the cost of hiring other programmers, I am optimizing for highest efficiency (as opposed to getting as much done as possible).  So far it seems like the best thing they can do is track down tangents (e.g. go find an android QR code library that actually works and write test code) so that I don't get distracted from the heavy lifting.

I will probably let at least one of them start editing the main code base.  I'd like to see if he is capable of working on bugs/tech debt, and also writing unit/integration tests.  I feel like as soon as I have him touch the made codebase, though, I lose "bragging rights" to say I wrote the whole app myself.   However, a finished app makes money;  bragging rights do not make money.  And its not like my ego needs to be fed.