I try to start every programming task with some thought.
I don’t mean thought as in hacking things together to see what works.
I mean some thought as in thinking about possible solutions and refusing the accept the first one.
I think this is a lost art. As programmers, we spend more time accepting solutions then we do thinking through solutions to make sure we are solving the right problem in the best possible way.
Spending a few minutes scribbling down some notes in a notebook might be the best thing you can do to develop better solutions to problems.Read Thinking is Underrated →
Steve Blank has the best article on startups and investing I have ever seen. It all boils down to a liquidation event. You are taking investment money to dump off your company. Well, in most cases you are. Sometimes an IPO is a target, but more often than not you are looking for a payday. Let me rephrase that. Your investors are looking for a payday.
That doesn’t mean investment is bad. Just that any founder of a startup should know what they are getting into.
In my personal opinion, investment is okay, given the company is profitable and there is plan to pay back the investors.
Know what you are getting into.Read Startups and The Liquidation Event →
In college, I took a lot of electives that had to do with networking and other topics that didn’t have a lot to do with programming. In one class I was given the option to read Takedown: The Pursuit and Capture of Kevin Mitnick by the Man Who Did It. A book about the most prolific hacker in history. I quickly realized that hacking has less to do with computers and more to do with humans. Through Social Engineering, a person can you your own tendencies and the faults of humans to gain access to what they need to get to your stuff.
If you haven’t read about Kevin Mitnick, and are interested in how people get hacked, read that book. If you want a quick look into how Social Engineering works, watch this video.Read Hacking is All About Social Engineering →
Have you ever thought about why it’s called lending a helping hand?
Because it’s temporary.
You are extended something that someone gave you. Good will. It’s a loan. A loan that should be paid back in the form of your good will towards someone else, the first chance that presents itself.Read Lending a Helping Hand →
Working on a new app and decided to try a styleguide that lives and breathes through the CSS. I’m happy with how it’s turning out.
Read Living Styleguides →
I listen to quite a few podcasts. Probably more than I should. Honestly, I delete most of the episodes. So I guess I could say I subscribe to a bunch of podcasts. One of those, Software Engineering Daily, recently had Seth Godin on as a guest.
I am a Godin fan. He’s not really a developer, but has some great things to say about business and doing your best work.
You should listen to the episode, it’s pretty great. Definitely some stuff that carries over to creating software.
One thing stuck out to me. Something I have been thinking about for a while. Seth was talking about how one of his companies needed an application built. So they created a spec, with design comps and details (I assume a functional document), and took those to an agency in New York.
They asked the agency how long it would take to build the app. The agency replied ‘three months’. Seth replied ‘Good. See you in three months’.
In today’s agile world, this seems crazy. But glorious.
Think about that for a minute. No scope creep. No changes unless a formal request is made.
But we know this doesn’t usually work. Seth Godin is the ideal client working with a top level agency in New York City. Defining scope before hand and forcing changes to be a formal request simply doesn’t work for many clients.
But maybe it could.
Something along the lines of a blueprint.
This is how engineers work. They design a structure, hand over a blueprint, and that’s what gets built. If there is a design flaw, it’s on the engineer to fix it. As a former construction worker, I totally get this.
I like the idea of a blueprint. A well thought out, defined requirements documents with a visual representation of what is being built.
I imagine a blueprint for a software project very similar to that of a construction project.Read The Blueprint →
I work through a lot of pull requests. Well, I guess that can be debated. There is always someone working with more. I guess I could say that I work with a considerable amount of pull requests. At any rate, I’ve learned quite a bit about handling feedback well. Handling feedback doubles in it”s importance when working remote. It’s easy to come across as a jerk.
The number one thing you can do to come across in a confrontational manner is just ask a question without context. Not just any question. Not like “Where did you find this amazing code?”. More passive aggressive questions like “Why is this here?”.
Asking a question like that seems logical. I mean, you are simply asking why this one thing exists. But it can come across as “I hate this thing! I don’t why it’s here and I want it removed. Why do we have it!?”
A better approach is a statement, followed by a question.
“This looks very similar to the code in the User model. Are we sure we need this?”
Now you setting up a question with context. The reader can see that you simply think that the code is unnecessary because you think it’s already been written. That one sentence removes any chance that the reader might think that you are questioning his ability, or even his intelligence.Read Pull Request Etiquette →
Software is almost always temporary. Especially when it’s free. Free just means that the creators have chosen to not charge for their software yet.
The issue is when they never really figure out how to charge for the software. They just kill it. Err, I mean sunset it. Or whatever you call it when someone kills a product you use and depend on.
The dirty little secret is that they don’t really care about the software. They had an end game and it didn’t work out. Your loyalty and data are often just a casualty of them not finding a business model.Read You Can Build Better Software Yourself →
Defining methods in Ruby is pretty simple. Type
def, a name for your method, then some code, and finally
endit. It looks like this
def name …code end
Maybe undefine isn’t the right word. I think hides is a better description. It hides the method.Read Using undef in Ruby →
I often think about doing something cool and talk myself out of it. Lately it’s been some sort of screencast site where I teach some programming thing. Nothing big. Just small things. Maybe once a week. I would need a library of videos built up before. That’s where I get derailed. All this thinking and planning. And then. I do nothing. Over and over again. I do nothing.Read Do Nothing →
subscribe via RSS