Data Science Essentials in Python

I was looking for a programming book my daughter and I could work on together, so we're going to tackle the one I got in 2016 that I had to forgo in March when things started to fall apart: Dmitry Zinoviev's Data Science Essentials in Python published by Pragmatic Programmer.  I made it through a few of the use cases and I think it will be a good book for daddy/daughter coding time.  Not to mention I can piggy back off some of it for Python for kids revamping for next summer which I just haven't found time to rewrite although it desperately needs it to make it more hands on, even though the focus is Python + Turtle so there's graphical feedback.

It's strange, but there are no reviews on Amazon.  I made it through the first few chapters Q1 2016 and I remember it being basic, but beyond simple Python, and the examples required quite a bit of thinking and independent research (parsers, etc), making it a great little textbook.  I'm hoping it'll spur some conversation while we code because that's really what most (collaborative) coding is about in my experience.  Yesterday, "What is Data Science."  Today, "Hello ."

Troubleshooting

The presenter in the Scavengers tutorial barrels along faster than I can type, and I'm not slow.  I was pretty sure I'd miss something.  And I did.  My food and soda wouldn't pick up and it took me a long time to realize I'd misnamed my method with 2d instead of a 2D.

But what really got me wasn't something I could control.  When my level was resetting, it wouldn't recreate the board.  I changed from a deprecated method to the new loadscene version.  And then I started putting in debug.log statements (didn't I say this felt like old school VB once before?).  After trying to narrow it down, it appeared my Awake function wasn't triggering, so the board wasn't repopulating.  I compared their completed version with my version of the script, and the prefab, everything else, all to no avail.  Finally, in this five year old post (long before the current version of Unity) someone mentioned that Awake() doesn't always refire and you have to code it up under OnLevelWasLoaded() to catch logic after the first time.  I dropped it in there - cut and paste rather than appropriate refactoring - and success!  So for anyone else who's getting Awake() or InitGame() events that aren't firing when they expect them to, OnLevelWasLoaded() is a good place to call your logic again to be sure it triggers.

You can see the affect of the bug on not rebuilding subsequent levels in the video.

Disturbing

I messed up the animation script for the roguelike tutorial in Unity.  It's a little worrisome looking.  I said at one point he was just standing around wanking.  Seems even shadier in this video.

Enemies

Reorg day!  The best, right? This one looks like it will be "directionally correct" in that I go from several business units to just one (but one with multiple people) all pointing at similar functionality even though it's in multiple products.  One of my rules has always been that if you can minimize business units, you're better off.  Gives your life a focus you don't get with half a dozen of them competing for your priorities and you ending up feeling like you're not making anyone feel special (or happy).

But on to a bit of code.  Although, as I think I've said before, I'm not sure this counts as anything other than configuration coding as long as I'm generally following video instructions.  But fun.  I got the enemies running with tilt and shooting, so altogether, it actually looks like a real game.

One of the things I noticed is that my bolts weren't deinstantiating even though I'd set it up.  Eventually I realized that it had to do with turning off the GameController which was the object controlling destruction of the bolts after a while.  It's just a checkbox, but it makes a big difference.  It also controls whether the enemy ships can actually destroy your player ship, so it's pretty obvious when you've temporarily disabled it.

Here's the video of the full game in action.  I upgraded to a record with sound so you can appreciate the music and the explosions.

Technical Debt Metaphors Get it so Wrong

This is just a scratch on the surface, but I like the following statement from Technical Debt Metaphors Get It so Wrong and, anecdotally (only because I've never bothered to formally track it), I concur that developers will feel the pain (and try to hide it) before it impacts the business.

 "This isn’t a simple language problem. It is a fundamental misunderstanding of roles that is naive to the way software development works. Programmers will be the primary sufferers of technical debt. Eventually the business will suffer with a slower pace of innovation and development and higher turnover. But well before that, programmers will be fixing (and refixing) obscure bugs, will bristle under management that tells them to go faster, will be working extra hours to try to improve things, and will eventually burn out. The business will only suffer once real damage has been done to a programming team, and many have given up."

Erik once crafted a Snrky related to Technical Debt:
http://www.snrky.com/2013/02/does-this-mean-were-headed-over_21.html

So did I, although a lot less technical:
http://www.snrky.com/2012/01/deduct-it-from-you-iou.html

What I Look for in a Junior Developer

Bill Gathen's article is spot on as far as I'm concerned. Those soft skills and the ability to ask questions and pay attention to detail are incredibly important. In several interviews I've been in (being interviewed, not giving the interview, and I include talking to new managers when I move between teams) I've told them I'm someone who doesn't drop a thread - that my consistency and ability to pick something up and still be motivated and feel a sense of ownership sets me apart from others. It doesn't just apply to development. Thinking creatively about your job and how to do it better and more efficiently and why it's being done at all - that should never go away, no matter how miserable the job is (and I've been a bulk mailer and cleaning services employee in my life, including the part that involves scrubbing other people's toilets). From a dev perspective, the one thing I'd disagree with is that I expect you to be able to talk about the tech. That enthusiasm you have should extend right down to the research you did for the opening I have. Yes, I don't care if it's PHP and you're looking for a .NET job, but I really hope that if you want a career in development you can talk the talk about what personally excites you and then...then...make the connections between your comp sci education/experience and my project (I'm picturing my daughter from her elementary years when the teacher made her link her hands together with two OK signs and say "connections").

"The ones I consider most important are: enthusiasm, attention to detail, a hunger for learning, and thirst to contribute."

Cultures of Code

"What’s the difference between computer science, computational science, and software development..."

 A good article in American Scientist about different cultures of coding. When i started (and I should confess, I'm a History/English/Writing major) in AeroE, I would say RPI was training me more as a computational scientist: modeling data and computational problems. Where I landed roughly ten years later was definitely the software development culture. Every now and then I run into a developer who tells me a variation of the following statement below - that we get lots of good software developers who know the languages, but that don't know their "basics". Admittedly, in my experience, we hire for the former, not the latter. Perhaps in part because they create copious amounts of business-requested code (features), even if it's not based entirely in the fundamentals. It's a bit of a conundrum and we seem to juggle it a bit by having a separate R&D group as well as some groups that balance on that line between software development and computational science and even computer science that can focus on the underlying efficiency and methodology rather than delivering external user features.

 "Programmers today are intensely partisan in their choices of programming languages, yet interest in the underlying principles seems to have waned. Two years ago I attended a lunch-table talk by a young graduate student who had turned away from humanities and business studies to take up a new life designing software. She had fallen in love with coding, and she spoke eloquently of its attractions and rewards. But she also took a swipe at the traditional computer science curriculum. “No one cares much about LR(1) parsers anymore,” she said, referring to one of the classic tools of language processing. The remark saddened me because the theory of parsing is a thing of beauty. At the very least it is a historical landmark that no one should pass by without stopping to read the plaque. But, as Edith Wharton wrote, “Life has a way of overgrowing its achievements as well as its ruins.”"

Notable Women in Computing

Argh...I wish I had caught this when it was on Kickstarter. Yet more proof the internet does not work as well as it should - any reasonably competent AI that traced my web history would have realized this was of interest to me. Looking back to only yesterday I was reading an article on COBOL and Grace Hopper. Fortunately, there are downloaded files so I can reach out to my friend in the printing space to get some posters and decks of cards.
CRA-W WIKIPEDIA Project - Writing Wikipedia Pages for Famous Women and Notable Women in Computing

Tech Debt 101

A good article on Tech Debt. I had no idea what a puxadinho or a favela was before this article.

"The puxadinho is the standard pattern that builts up whole “favelas”, the brazilian slums."

Remember to Clean Up

I was going to add this picture to a post about sexy Marvin the Martian costumes after seeing it on the web.  So it's been sitting around on my desktop for weeks.  Isn't she fetching?

But during the time between saving the picture, and this post, I helped a friend troubleshoot a web app.  What the two things have in common is that I tested the upload functionality of the app repeatedly, using this image of Ms. Martian.  So when all the files were dropped back into Dropbox, there were probably 100 copies of this file (part of the upload process was to tag the files with a numeric portion so there wasn't duplication, even if two people uploaded Readme.txt) in the mix.  The Dropbox folder was shared with the friend's client.  Fortunately, while sitting around reading, some part of my brain thought about the picture.  And then I thought about testing the app.  And then I drew the line from A to B (B1..B100).  I'll be interested to know if Dropbox prompts the client with "100 files removed from Dropbox."

Front Controller

If you're just starting a chapter on MVC, this does not explain the Front Controller pattern at all.

Object Oriented...

Last night I had a dream about how a serial killer was stalking local picnics and killing families of picnickers.  More of a nightmare, because it was sort of gruesome.  Mean Mr. Mustard and Erik the Hairy Swede showed up to discuss how best to combat the killer, and we all had an argument about the best method.  I said we should put a weapon in each picnic basket.  Mean Mr. Mustard said that was dumb, and we should give each individual a weapon.  Erik said we should treat each outing separately and the weapon should be associated with the picnicking event, not the basket or a person.  At which point I woke up and realized my dream was not about picnicking or about serial killers, but about appropriate object oriented programming.

Smart Girl!

Eryn wants to know how to code.  I taught her a little bit of Ruby once upon a time (we played with Shoes), but she asked if I'd teach her C# because she knows that's what I used when I did programming for a living (I haven't given her the article "Why We Don't Hire .Net Programmers" to read).  We started out with a simple Console app so we could play around with loops and writing to the console.

int counter = 0;

            for (long i = 1; i <= 100; i++)
            {
                Console.WriteLine(i + " My name is Eryn");
                counter = counter + i;
            }
            Console.WriteLine("Counter is: " + counter);

She was having fun increasing the counter value by a magnitude and watching it hop from 5050 to larger numbers.  But after she threw in a million and waited for the loop to end, she asked, "Hey, why isn't the number as consistent as the other numbers were?"  That's right...she intuitively debugged the fact that the int datatype wasn't sufficient to hold the sum of all the numbers up to a million without creating a problem in the output.  We discussed bugs and what a bug like that might have meant if you were trying to write code for the space shuttle.  Fun!

Shoes

Two weekends ago, at Code Camp, I went to a presentation on Shoes, a Ruby-based IDE that includes Ruby in the install. It's not exactly enterprise ready and sometimes it dies on me, but if you're trying to teach your kid to program, it took Eryn just a few minutes to pick up a few of the basics. It's particularly easy to learn and you can do some fancy things like access Twitter or Flicker or YouTube without having to know low level programming functions.

Code Freeze 2009

I just noticed this in my drafts. I started writing up some details around Code Freeze, and then just left it sitting there. For some reason, I thought I had posted it. I'm only posting it now so it gets indexed and I don't forget the books/links I was interseted in from the conference...

Last week, on a day so cold we stayed in the sun while walking to lunch to avoid sticking to the sidewalk, a number of us from work attended the University of Minnesota Code Freeze 2009. In the past there have been a few coworkers there, but this year there was a complete contingent, including two coworkers who were coordinating the conference, folks from my department, folks from Findlaw, alumni of Findlaw, a folk from TTA, and others from the content area.

I've been to two other Code Freeze events in the past and the scope of the topic is generally pretty broad "Innovation" in 2008 (with a lot of Agile talk), "Global Systems, Global Development" in 2007 (with a lot of offshoring talk), and "Maximizing Developer Value" this year (a mix of how not to get interrupted, agile, estimating, testing and the odd other topic).

Neal Ford spoke on "On the Lam From the Furniture Police". I thought he was by far the most interesting speaker and his presentation was enjoyable with a good sense of humor and specifics about how to avoid "context-switching" as a developer, that problem we've all had that we just get going on code when someone drops by to talk about something completely unrelated. It's not just a developer problem. It happens to everyone. It even happens to managers, as I can attest in my recent role trying to coordinate two distinct workstreams that kept stepping on each other. When I worked with our large, priorprietary database, I worked with a dozen partners at once and seldom had issues with flipping from project to project (to project to project) even within the same few minutes. However, when I was doing the role of a data analyst and my standard role earlier in that job, when I had much less work overall, switching between the two roles often threw me for ten or fifteen minutes each time I moved from one to the other. It's interesting that context switching can be context specific.

Ford also talked about the value in engaging both sides of your brain, the logical and the holistic (intuitive, call it what you will - the side that says "aha" about problems). He then related this back to context switching by pointing out that it took a lot of work to get your right side engaged while coding, and context switching was death to your aha moments.

So what does Mr. Ford offer as ways to reduce context switching and engage right brain thinking? Toys - provide some little toys and brain teasers so that the left side of the brain is engaged in a repetative activity allowing the right side to override the noise. Get rid of "pin prick" distractions. Turn off your notifications. Use a tool like Tweak UI to turn off balloon tips. Employ a screen dimmer like Jedi Concentrate that ensures the window you're working with garners your attention. Use tools to track relationships like an external brain (he called it an exo-cortex): a notebook, Personal Brain (perhaps useful for writing a novel as well), Larry's Any Text File Plugin (in conjunction with Google Search), and using Rooted Views.

Use automation and continous integration to cut down on unnecessary distractions from your own code. Use virtual desktops to mimic how you would lay out papers on a larger desk. Have walking meetings. Exercise. Take a nap at 3:30 each day. Don't work in a cube. Avoid sitting where the noise is heterogenous instead of homogenous. I see this last one in effect at work almost every day. We have developers who work on a particular type of project and they seem very capable of flipping between those projects and avoiding the context switching associated with many projects, although we have initiatives to try and ensure that any one person is on a minimal number of projects for that reason. However, in the same area are developers who are on completely different types of work, whose day-to-day worries are more along the troubleshooting line, tackling a problem of the day, or a tricky hardware issue. When they meet to discuss the issue of the day, it can suddenly engulf everyone nearby, even developers from other areas who can't avoid the heterogenous noise.



Books mentioned:
Andy Hunt: Refactoring Your Wetware
Pragmatic Thinking and Learning
Peopleware: Productive Projects and Teams
Raston - Human Interface (locus of attention)
Flow: The Psychology of Optimal Experience
The Productive Programmer

Nate Schutta - Hacking Your Brain for Fun and Profit
Nate was the second presenter, and the only other one I want to talk about. Susan Standiford, Andy Miller, Tomo Lennox and Luke Francl were interesting, but they weren't on topic with anything that resonnated with me. Nate continued Neal's presentation in some respects, focusing on what there was in the brain of a developer that lent itself toward productivity. He focused on some of the physiological effects of not sleeping enough, not getting enough exercise, email apnea, and continuous partial attention. He offered up solutions such as no-meeting Fridays, f-off flags (in use at TR in a few places), and a zero inbox. All great ideas. While talking about the importance of sleep, he referenced these amusing videos of Peter Tripp staying awake for 8 days.

Part I - http://www.youtube.com/watch?v=mXrANL9aqz8
Part II - http://www.youtube.com/watch?v=2R8jNJFFzS0&feature=related

Books mentioned:
Brain Rules
A Whole New Mind
Mind Hacks
Your Brain: The Missing Manual
Lifehacker (GTD)
Getting Things Done
Pragmatic Thinking and Learning
43 Folders (web site)

MinneDemo

On Friday night I went to MinneDemo with Erik and Ming at the Intermedia Arts theater. I'd never been to a MinneDemo before, and if you haven't either the rules are that the presenters have to present on working software, have approximately seven minutes to complete their presentation, and cannot use a PowerPoint slide deck.

In addition, there's tons of networking with developers from around the Twin Cities. We bumped into Alan from work there, a friend of Erik's who used to work at Thomson, a guy from SAS who said I looked familiar (e.g. I look like my brother), Ed Kohler of The Deets (a real pleasure to talk to), Peter who used to work at Findlaw and was at CodeFreeze, and some guy who was sort of dressed as a poor man's ninja with a straw hat. For some reason that last guy focused on Ming, so the rest of us didn't have to deal with him. I'm not sure if he's the reason Ming snuck out later without telling us goodbye.

There was also free Surly. A lot of free Surly. I had the coffee and the Furious. The beer alone makes it the best developer event I've been to in a long time.

The presentations were good, at least the first four I saw. There were so many people at MinneDemo that only about 3/4 of them fit into the little auditorium. Even for the first four I was sitting on the stairs. There was a big screen in the entry way, where Erik and I stayed for the second half so that someone else could get a shot at the seats, but it was a bit fuzzy and impossible to hear. Fortunately, you can see them all at Minnov8. Re-searchr looked particularly interesting, albeit a bit slow. But they were streaming the presentations to the entry area, so it might have been a bit congested.

After the beer and the presentations, Erik and I went out for a late dinner at Fuji Ya Sushi on Lake. When we bellied up to the sushi bar, the place was packed. Two hours later we were completely alone. I hadn't been to Fuji Ya before and I strongly recommend the tuna flight (six pieces) and the tobiko wasabi roll that left little fish eggs all over the place. We were there long enough that the sushi chef prepared us a pineapple/strawberry/chocolate-raspberry sauce dessert as a free treat. Just a great evening.