I’m a huge fan of Alfred - but I had to upgrade to get the pro version to get workflows. Because I use Slack a lot, I’ve been trying to set up status automation and workflows. When using my phone, I have an automated system that sets my status. You can find that here. But, what about using Alfred for some automation?
The other day I was at a coffee shop and I looked around at all the Mac’s open. It used to be that you’d see people writing manuscripts at coffee houses. Surprisingly, this place held a lot of programmers. I suddenly thought of something interesting:
Over the course of many years, I’ve heard many variations of the same question “How do I learn programming?” Normally, I’m caught off-guard. I don’t know the answer. Things are constantly changing, and what was around “back then” may not be around now. Plus, I don’t exactly remember all of the steps I took to learn programming. Finally, the way I learned programming doesn’t make sense these days. Technology is much different - you wouldn’t consider dialing into a BBS or reading the manual that came from your computer, would you?
Interactive coding challenges during an interview are common place these days. The idea is that you’ll get an idea of the type and quality of work a candidate will produce by watching them code during an interview.
As a manager, I spend a lot of time delegating. I delegate small tasks so that I can spend more time adding value to the process and project. The value I bring is my ability to see the larger picture, use my experience as a guide, things like that. If I’m doing too many little things, I can’t do what I’m good at.
In an earlier post titled Use $this->fail() with Mockery::on(), I explained the challenges of debugging a failing test with the closure passed to Mockery::on(). Instead of returning false, I opted to use $this->fail() - which seemed like a good idea at the time. After all, I was doing my test, then failing with a useful bit of information. (Previous to this, it would just say that you don’t have a matching handler for this assertion, which was really confusing).
I experiment a lot with thoughts and process. I used to be scared of implementing something new because I felt like I was now married to that. Or, if it becomes habit, maybe I won’t want to stop it, even if it’s annoying (how irrational does that sound? But if you’re honest with yourself, you’ll see that happen a lot. If you ever hear “that’s just how we do it” then you’re experiencing it.)
You may know that you can host a static site on GitHub pages - but what if you want to have a www redirect and also SSL? This isn’t that hard until you get to the www redirect. That would require a subdomain and a second SSL cert, which they don’t provide.
Measurement is important. Metrics, while not sexy, are concrete to a good business strategy. When you bring a problem to your superiors, they’re going to want to know what is your measurement, what metrics did you use to determine this is a problem. With tasks I’ve given developers, I’ve always said “show me the metrics that your fix is better” versus just looking at the code.
Too often we find a team leader or a manager and just expect they’ll be able to hire new employees effectively. After all, they’re successful, they should be able to clone themselves, right?