Monday, October 17, 2016

Instant Runoff Elections would really solve problems right now.

Also, it's an interesting idea for a software programming exercise.

http://www.fairvote.org/rcv#rcvbenefits


Monday, February 22, 2016

Mentoring; JSP template tags


JSP templates

This was a really useful Stack Overflow answer on how to do templates in JSP.
http://stackoverflow.com/a/13103364/116810

Mentoring

My mentors have taught me some good tips on mentoring and knowledge sharing with coworkers.  The first one I will share today is this:
  • Tell them how to do it, but let them be at the keyboard doing it.
People remember more when they do it.  If you show them, they won't retain as much, and they won't be able to ask questions.

That said, I have learned a lot by watching other developers code.
  • Occasionally, sit with other developers while they write code.
I've learned things about problem solving techniques, skills with the IDE, and tools and APIs they use that I didn't know about.  I won't list those specific lessons here, but I will say that watching other developers code and do their work is invaluable.

A third thing I have learned about mentoring and skills growth:
  • Set goals to improve on your strengths, not just your weaknesses.
A while back I decided to work on my written communication skills with my manager.  I thought that writing was a strength, but as I started cc'ing my mentor on all my communications, I received feedback that helped me improve.  And I realized there are a lot of different skills that go into good written communication.  There were a few I could improve on.

I am inspired by the developer tea podcast, which shares small nuggets of insight and doesn't aim to be a long podcast.  Sometimes it's just 5 minutes.  Short podcasts are great.  So are short blog posts.  It makes me feel less worried about how in depth and helpful my blog posts are.

Friday, February 12, 2016

Vue.js?

I've heard from some coworkers about vue.js.  I like what I have heard in this podcast episode.  However, my main concern is corporate backing.  If Evan You becomes unable to keep development going, I get the feeling the project will struggle.  I'm sure someone will step up.  Also, I feel slightly concerned that in the interview the creator didn't have a clear vision of where to go next.

I hope vue.js gets some corporate backing.  I hope it works out.  I don't know if I would develop an enterprise app using it just yet.

Tuesday, January 26, 2016

Scribbled notes: Blind spots as developers. Working notes. Assumptions.

Blind spots.

A not-so-recent project I worked on convinced me that well meaning assumptions can cost us frustration and time.  I was tasked with fixing a bug where duplicate records were showing up in a search tool for certain financial data.  The more I tried to understand what the code was doing (specifically a SQL join on an arcane AS400 database), the more confused I felt.

Finally, I realized that the original developer had assumed that certain columns were meant for JOIN conditions, when in fact that assumption was utterly wrong.  The data relationships were much looser than originally thought, and the data simply could not be displayed in the old way anymore.  To fix the bug, I had to redesign the report with progressive disclosure at each level.

The original developer had trusted some (wrong) intuition, and what some accountants had probably told him.  I had trusted that the original application SQL was written with a correct concept of the data model.

We all have blind spots.  I've since learned not to trust that the original design was even correct (it was good enough to get by on, but it confused and frustrated people often).

(The original query had joined on "line item numbers", but a check line item isn't the same as a document line item--they are only related by document, not line number; checks could be written for multiple documents, and documents could be handled by multiple checks)...

Anyway, just watch out for assumptions.  You have to make them and live with them, but just be aware of them and list them, before you forget you made them.  Keep working notes as you do your job.  They'll get better over time.

Scribbled notes: podcasts I like, learning as a developer, the advantage of blogging ordinary things.

I am going to play with an idea I got from this podcast and another:
https://developertea.com/episodes/24531

The idea is that we should share un-refined lessons we are learning as IT workers.  The basic idea is that you should share things you learn, without fear, because it helps everyone (I can learn by expressing, you can learn from me--or I hope so).   I'll see how it goes for me.  Maybe I won't do it much.  But I'll try it out.

By the way, Developer Tea is a great podcast.  I listen to podcasts on my 30+ minute commute. Go check out some of the episode titles and see if you like the gist of Developer Tea.  It's short--episodes range from 5 to 30 minutes, but are never too long (I stopped listening to the 2 hour "this week in tech" a long time ago.  Sorry, too much fluff, too much time).

"The Web Ahead" and "Javascript Jabber" are fairly good podcasts too.  If you're a Java developer, "Java Pub House".   If you do AngularJS, try "Adventures in Angular".

If you know any wiki pages with a good list of podcasts (current, updated), let me know in the comments.

(I used Player FM on Android to listen to my podcasts; I thought Podcast Addict was fairly good too).

Notes from the Developer Tea episode:
It's difficult to learn on the job.  How do we shift our and others's perceptions to enable learning?

  • Don't be a closet learner.  You may get opportunities to do new things.  You will have more conversations, which helps you and others.
  • Don't share what you are learning right away.  If you fail, it looks bad.  Show successes and value, not failures.
  • Focus on learning in low stakes situations.  Especially on the job.
    • Early in projects.  
    • 1 or 2 new technologies within your current stack, not a new stack all at once.
  • Spend time with someone who already knows more than you.
    • Don't be needy, exhaust their energy.
    • Gives you things you can't manufacture on your own.
    • They can know you and your mind and learning style.

Here's the Web Ahead episode that also inspired me, with some transcript, that influenced me to write here more.  (note, they were talking about how simple boring blog posts make a big difference, the quote is slightly out of context)

Jen
I think it can overwhelming when you're trying to get work done. I think it's fun when you realize how lucky we are to be at the beginning of something so new. Anyone listening can investigate something, write a blog post, and influence the entire industry. They can change the shape of the medium itself. Which is so crazy.
My notes: I should interject here, I think the idea is that Jen and Jeremy feel ordinary, yet have been influential to others.  And they see other people in the same boat.  They talk about influencing just a few people, if I recall correctly.


Jeremy
 I wish people would write more. For that reason that you mentioned. In the future, we would have a better understanding of what people are thinking now. I'm very glad that I've been doing my blog for 15 years. I can go back to 2002 and get a feel for what it was like to build websites. Back then we thought X was true or hadn't even considered Y. You forget these things. Having these written records — not of anything important or groundbreaking — but just the day-to-day. The boring stuff. That's actually what's most interesting over time. I wish people would write more boring blog posts. [Both laugh] “I went to work. I did this. Nothing groundbreaking. Nothing revolutionary. But that's how we build websites today.”
Jen
We used to write a lot of boring blog posts. Then we stopped when it felt like audience was so important: “I don't want to say something that's going to embarrass me later. Everything should be really well-written and polished. I don't have time to write something that great.”
Jeremy
I hate it when people self-censor like that. They feel like it has to meet some standard. Again, it's the web. The whole point of the web is there isn't a gatekeeper. There isn't someone with a red pen saying, “That isn't good enough to be published. That's not up to scratch. You're not allowed to publish it.” There's no app store keeper for your writing. Yet people impose it on themselves. “I'm not good enough. My writing isn't good enough.” It's the web. It could be the worst thing ever and you still have the right to publish it on your website. You should do it. Don't let anyone tell you otherwise. I feel like a lot of people have this self-censorship thing.



http://thewebahead.net/110



Let me know if this turns you off to reading my blog (all 4 or 5 of you who read this).  Or if it inspires you.

Anyway.  That's it for now.

Friday, July 24, 2015

Re-post: Dropdowns are usually the wrong choice for UI.

Especially on mobile sites, dropdowns are a huge burden to user input.

http://www.lukew.com/ff/entry.asp?1950&utm_source=hackernewsletter&utm_medium=email&utm_term=design

"But because they are hard to navigate, hide options by default, don't support hierarchies, and only enable selection not editing, dropdowns shouldn't be the first UI control you reach for. In today's software designs, they often are."

He suggests finding the right alternative in each case, such as steppers, radio groups, sliders, switches, 2-way sliders, button groups, date pickers, and so forth.