Tempted

Blog

EW! Gross!

Blog

I like my coworkers' sense of humour.

The E and the W are the W and the E in the word WEST. I have the different directions on each wall, because the water is no longer in the correct direction to orient me. The E has a backing I haven't been able to remove, so the W and the E haven't been hung on the wall yet.

Clearly a coworker noticed.

Nine Dragons

Book Notes

Harry Bosch, Book 15

With the speed that I have been reading these Bosch books, you'd think that I really enjoy them. You'd be somewhat right, I do enjoy them, but not necessarily really enjoy them. They are entertaining, to be sure.

So, in this book, as in thirteen of the last fourteen books, someone dies and there are tunnels. I know, I know, you're expecting me to say, "AND A BAD COP DID IT." Well, sorta. Read the book to understand what I mean. The series definitely took a right turn in the middle of it to a point of complete "Wait, WTF. Did that just happen?" The emotional stuntness (is that a word? it's a word now) of Bosch (okay, of Connelly's portrayal of Bosch) is stunning. The man cannot describe emotions to save his life. There is a dark abyss of raw pain that people descend into at certain points of their lives. That Connelly was unable to describe it well leads me to believe that Bosch's "mission" is a cover for his sociopathy. Here, let's look at Wikipedia's definition:

Psychopathy (/saɪˈkɒpəθi/), also known as—though sometimes distinguished from—sociopathy (/ˈsoʊsiəˌpæθi/), is traditionally defined as a personality disorder characterized by enduring antisocial behavior, diminished empathy and remorse, and disinhibited or bold behavior.

Antisocial? Check!
Diminished remorse? In this book, check!
Bold behavior? Check!

I understand the plot minimized the time available for any kind of mourning in the book, but come on, Bosch does not do emotions (or Connelly can't write them, I don't know which, as I don't know if being emotionally stunted is a deliberate creative choice).

Look at me, finally analyzing the characters!

Anyway, it was a fast read. Good enough to continue reading the series if you're already a Bosch fan. There's a left (right?) turn in the middle of the book that is stunning, so way worth reading if you're already invested in the series. If you haven't started, don't jump in the middle, go read books 1-3 to see if you like the series.

How to Transform Your Ideas into Software Products

Book Notes

This is my review of the book for work:

Finished reading How to Transform Your Ideas into Software Products - it was a Shopify Montreal library book, and, I think, a great choice. I read it in about 3 days on the bus rides into work, so it's a quick read. It's a guidebook on how to build software from validating an idea before writing software, through user personas and stories, designing workflows with paper, prototyping guidelines, basic marketing strategies and metrics. The typography and copy-editing needs work; the book has no ISBN [edit: the copy I have doesn't, but the book does: 978-1-4951-4124-9], and is available at http://femgineer.com/transform-ideas/ and Amazon.

Okay, that's the blurb of it. The opinion of it: if you already know all of this information, if you already write code and know about full product life-cycles, then, sure, all you're going to get out of this book is how much it needed a copy-editor before publishing.

However, it is the PERFECT book to hand to someone who doesn't write software or is new to software development, and wants to take an idea through to project launch and growth. It's a great roadmap: it's not deep in any area, but points the reader in the right direction.

My new plan for people who approach me at conferences with ideas they want to build is now recommend this book and suggest they do the exercises through chapter 7, then come back and we'll talk.

I recommend this book for software people as a blueprint, it's an easy read and eye-opening to all the things you already know but everyone else doesn't. For non-software people, this is the perfect blueprint for building a software product.

Ignore the typos and the "you've gottas."

Of note, I have it as a work-provided book. Work has this amazing library where employees are allowed to take books from the library to read, and return if they want or keep them if they'd like. I love this idea. Many of the books are business books, some are inspirational books. It's a great idea for a library.

Notes while reading:

If your book has a "you've gotta" in it, then you've gotta have an editor before you publish. A number of these odd speech patterns and assorted typos are distracting while reading. I would argue having someone do the typography design would also benefit this book. The tiny print, tall line spacing and small margins make the book difficult to read. Bigger fonts and thinner paper would have been a great improvement for the readability and feel of this book.

The exercises in the book are great.

Wow, is it easy to forget just how much one learns over the course of a career writing software for a living.

Questions to ask self in weekly reviews (similar to what I already ask, actually):

1. How much time did you spend on your idea this week?
2. If you didn't spend any time this week, why not?
3. Will you be able to set aside the same amount of time next week? If not, why not?
4. If you worked on your idea this week, what were the specific tasks you did and were there any results (doesn't matter if they were positive or negative)?
5. Is there anything you are stuck on? What is it?
6. If you did get stuck, who do you know who could help you, and what is the specific help you need from them? Or do you need to do some thinking or research on your own?
7. Set 1-2 goals for the following week (eg "do exercise 1 in chapter 3")

Recommended.

"It should just work."

Blog

"That never happens."

Well, I'm looking at it happening right now.

"It should just work."

Well, it doesn't.

"It doesn't do that."

Well, it's doing it right now.

I have a coworker whose reaction to something that doesn't fit his view of the world is to deny it. He doesn't ask for more details. He doesn't ask for clarification of the problem at hand. He doesn't help the person asking for help, he just tells them they are wrong.

The company is big enough that I don't actually know where this guy is in the organizational structure. I do know that I seriously hope he isn't in any support or development role. This company writes software, and any sufficiently complex software has bugs. To categorically deny what other developers are seeing, likely developers who are nose-deep in the code and seeing something odd RIGHT AT THAT MOMENT, makes this guy an ass. In every interaction I have had directly with this guy, he has been wrong. In every interaction I have witnessed this guy in, he has been wrong.

If you're that ass, stop it. Stop assuming your viewpoint is correct and start asking questions to better understand what is going on.

If you're not that ass, good. Keep asking questions, keep working to understand what the other person is seeing. You're doing it right.

Pages