# Endurance Learning

“Judge each day by the seeds you plant, not the harvest you reap”

Teaching your child to ride on a bicycle is very fulfilling, but can also be frustrating to both you and your child. This is a learning path with very little shortcuts. Your child can’t just nod and say “I got you”. She actually needs to get on that bike and ride. And stop. And not fall… and falling hurts… And pulling through those falls require, sometimes for the first time in your child’s adult life, to trust you that your teaching will work. That it’s ok that they fell, and that although it seems hard and painful, the outcome will be worth it. “Remeber now that it’s hard”, I told my son when teaching him to ride his bike, “remember now, and when you ride your bicycle freely and enjoy it – look back and say ‘it was worth it'”.

When facing a complex subject or a problem, a common pattern for dealing with it is called http://diplateevo.com/2013/01/forecasting-confidence-levels-with-the-bipolar-learning-graph/. Getting the basic concepts is easy (you put your hands on the handlebar, your legs on the pedals, and go…), but then you fall… and even when you are able to ride a little, it’s hard and not fun. But then – you get it. And then your confidence grows, and then you become proficient and effective (and enjoy). The problem is, if you don’t believe in the path, it’s very easy to drop just before you get to the ‘infection point’.

If you manage people, you many times act as their mentor and teacher. And sometimes it’s hard to explain why things are not adding up, and why success seem far away. And your people need to trust you that you lead them towards the right direction. When a project fails (and projects fail…), you hopefully look back and learn, aiming to improve the next time. But when a project succeeds – remind them that it was not trivial. That it succeeded because they endured through the process, and did not give up when it was hard. And now they can enjoy the ride…

# Engineering Managers Should Code 31% of Their Time

Well…
I think the saying shouldn’t be “Managers should code X% of their time”. That’s just a tabloid/provocative headline, and it’s about getting a higher CTR (I took it one step further, ha!)…
Leadership can come from a lot of places:
• You can be the most charismatic guy in the room.
• You may have superior technical skills.
• You can have awesome interpersonal skills and the ability to find what drives any other person.
• You may have all the right answers and be great in prioritizing tasks.
• Or very big balls…
In many cases, leadership is about a combination of the above (not limited to it, obviously).
What I strongly believe in, is that you can’t be a great leader and an excellent manager if there’s not a minimal amount of each ingredient.
• If you don’t have any charisma – you’re a handicapped leader.
• If you have no clue regarding the technology your team is using – you’re a handicapped manager.
• If you lack interpersonal skills – you’re handicapped.
• If you can’t say what’s right and what’s next – handicapped.
• No guts? Handicapped…

# Goals

Goals are a good thing. You feel motivated to pursue them, you feel satisfied when you reach them.
You probably heard about SMART goals. If not, here’s a good place to start: http://en.wikipedia.org/wiki/SMART_criteria
For your yearly planning or retrospective, SMART goals are a good tool to use.
But…
Here’s a thought I had: you owe yourself a BFG (patent pending, but inspiration comes from http://en.wikipedia.org/wiki/BFG_(weapon)). A Big Freaking Goal (I know, it’s not freaking originally, but I aim towards young readers as well…).
Anyone needs at least one BFG. You don’t want to have too many of those, as they’re big, barely achievable (if you tell to other people about your BFG, they might thing you’re crazy or disconnected or immature or over ambitious or, well, you get the point), but it’s your BFG.
Maybe an example or two would help here:

• Climbing Mt. Everest.
• Be a CEO of a successful company.
• Reinvent Shopping…
A good method to distinguish a BFG from your regular SMART goal is that it’s a goal that you can’t see what happens after you achieve it.
You can’t imagine yourself taking the next step beyond your BFG. It’s just that big.
But it’ll be something you wake up in the morning, anticipating, thinking what you can do today to take one more step towards your BFG. In my world, that’s a good thing…

# Surprises

Some people say they like to be surprised. Sometimes it can be fun, really.

Most people don’t like to be surprised, though, especially not in their ‘professional life’. Surprises are rarely good nor fun…

There’s an old saying (well, not really old, not much of a saying) which goes something like: “If you don’t want to be surprised, don’t surprise others”.

The surprises I’m talking about can be many. For example, but not limited to:

• You’re going to miss a deadline.
• Your availability is going to change dramatically (going on a long vacation, for example)
• You need to change an agreed understanding between you and a peer.
• And more..

All of the above can be handled and nothing catastrophic will happen (probably), but the sooner your peers/managers learn about it, the better they can help you (and themselves) deal with the results.

You can also choose to not communicate the news because, hey, it’s going to happen anyway and you can handle it alone (and why bother others so early in advance), but then you might be surprised by their response once they learn about it in the last minute (or a little afterwards).

And as already mentioned above – if you don’t want to be surprised, don’t surprise others…

# How to never fail

In rock climbing, courses are graded based on their difficulty, and in general, the higher the grade the harder the course. There are several grading scales, where one of the popular ones is the Yosemite Decimal System. On that scale, the 5.12 grade is considered magical, and for many intermediate climbers it is considered to be out of reach.

For climbers aiming to beat the challenge of climbing a 5.12 wall, one of the more important lessons is: fall. The fear of falling during the climb stops you from trying difficult moves, keeps you from testing your limits and eventually prevents you from pushing your performance envelope. So – fall. Again and again, first in a controlled environment where you know nothing bad will happen, then fall from a little higher (you’re always connected to the rope, and you must always follow all safety procedures) – but trust your equipment and, more importantly, trust yourself.

In Software development, there are many ways you can fail – you could miss deadlines, you could have bugs, the project could exceed its budget, the customer may not be happy with the results, and it could be all of the above. So we add guards – we create a project plan, get a bug tracking system in place, do automatic testing, make sure there are reviews and reviews of reviews, get a project manager, a program manager a product manager and development manager, make sure they all meet and update each other regularly, and we then add the secret ingredient – a buffer.

What’s good about buffers is that you can never have too many of them. And if you fail, the easiest way to learn from your mistake is: add some more buffers next time. The problem is, in my view, that we’re getting too used to buffers. At times we don’t even remember why we added some of them to begin with, we just know that if we don’t do another review, get another meeting in place or add some extra time – something really bad is going to happen.

No one likes it when bad things happen to them. No one like to fall. It hurts, and you could get injured. But aren’t we missing an opportunity to learn what we can really do? Isn’t adding another buffer a dangerous block to seeing what our limits really are?

I realize there are many open questions here (like: are the customers willing to pay for you taking extra risks, and should they? can you actually control the amount of risk being taken without getting yourself killed in the process?). It may be that when things get complicated enough, when the project becomes big enough, you just have to add brakes and balances, or you will cause more damage than good. But does it mean we have to give up on our full potential at this point?

# So, one of your employees think they have a great idea…

In a marketing book I once read (entitled Marketing Managment (2000), by Prof. Jacob Hornik and Prof. Phillip Kotler) there’s a chapter about introducing a change into an organization.

Besides discussing various ways to do that, the chapter also talks about the forces fighting the change, and brings a list of ‘common yet effective ways to fight change’, here it is:

Employee: “I have a great idea!”

Manager – quickly choose one or more of the following responses:

• It will never work for this organization.
• We tried it before.
• This is not the right time.
• It can’t be done.
• We don’t work that way.
• We’re doing great without this.
• It’s too expensive.
• Let’s discuss this in our next meeting.

# Management and Momentum

There are many roles a manager needs to fill. The manager is accountable for the team’s goals, helping individuals perform, give feedback and measure performance, act as a mentor and a leader, make decisions and, well, more…

When I ask other managers how they see their role, the answers vary, covering some of the points I mentioned above and others as well. People who practice agile methodologies mention on many occasions that one of the important roles of a manager is to clear the path for the team, so they can do their magic.

While I agree with and can relate to most of the various roles, there is one aspect of the day-to-day managerial work which I didn’t get to hear much, and it’s about momentum.

Once things are in motion, it’s relatively easy to maintain movement (yes, you still need to clear the path so you won’t lose momentum), but it can be tricky to set them into motion. It can at times be even harder to increase the speed (somehow slowing down usually gets done by itself).

As a mangaer, you are where people look to. If they see you moving, they are more likely to move. If they see you just sitting there they may think it’s ok to slow down a little. If they see you running and they trust you know what you’re doing, chances are they will run as well.

I’ve been in companies where from time to time they’d gather an all-hands meeting and say ‘we’re facing some challenging goals, it’s going to be a tough period, brace your selves and let your spouses know: you’re going to be working hard’. Much more often than not, this ‘fake sense of urgency’ achieved exactly the opposite. I worked hardest when the leaders of the organization made me feel they are invested in the goal at least as much as I am (and much more). And it’s not just about staying late or working weekends, it’s about constant involvement and actual care about what’s going on. You can’t be managing from your closed-door office. You want to be out there, in the trenches, with the people. You are the flywheel.

As the flywheel, you begin spinning. Your subordinates will catch momentum, spin around you and spin themselves. Their subordinates will follow. Sounds easy, right?

Momentum is a great thing to have – in physics it’s directly related to energy, I think it’s true for management as well.

[

if you’re interested, kinetic energy is calculated like so:

$E_k=frac{1}{2}cdot Icdot omega^2$,

where ω is the angular velocity, and I is the moment of inertia of the mass about the center of rotation. The moment of inertia is the measure resistance to torque applied on a spinning object (i.e. the higher the moment of inertia, the slower it will spin after being applied a given force)

[from Wikipedia]

].

# Team of Stars or a Star Team

One of the more exciting experiences I can think of as a manager is the opportunity to build a new team. Besides the chance to face new challenges, it has this feeling of going back to school after the summer vacation, with new books, new equipment and the feeling that you can be the best at what you do (well, now that you have new pencils!). In reality, though, recruiting in general and creating a team from scratch (or almost scratch) specifically is a very challenging task, and mistakes in that process could have a major impact later.

Even before you begin recruiting, you need to come up with a job description – besides being the baseline for the expectation setting between you and the candidates, the job description also serves as an initial sieve for the incoming flow of CVs. Set the requirements too high, and you may be losing good candidates (either because they feel intimidated or because they don’t meet a requirement you may be willing to compromise on – if you knew they were great in all the other stuff), but set them too low and you may be swamped with irrelevant CVs and spend most of your valuable time talking to the ‘wrong’ people. In order to understand where the bar should be set, I think there’s an important question you need to ask yourself – are you looking for a team of stars, or are you aiming to create a star team?

I think the answer is not trivial. Moreover, there are probably points in time where you’d be leaning towards recruiting stars and other times where you’ll be recruiting people to build a ‘star team’ (where no one in the team is necessarily a ‘star’ on his own).

For example, in a startup environment, probably in the early stages, where the team is very small, technological excellence is in many cases key for success and certain superb aspects of the product might be the difference between success and failure, you may want to have the star people who will be able to solely solve in innovative methods any given problem and make this one great feature which will make your product more attractive than the competition.

I think that once the team grows it both becomes harder to maintain an all-star team (there is more maintenance that needs to be done and less innovative work, there are increasing amounts of bugs that need to be solved, there’s more documentation to be created, and so on), and delivering quality software based on the customers requests, on time, is at least as important as innovation. The ability to share tasks, knowledge and ownership of a large codebase becomes critical to the team’s functionality. At this point you’ll still want to hire excellent engineers, but I believe you’ll want those who will appreciate the chance of being a part of something great, knowing that the fact that they belong to a star team actually makes them better engineers in the long run, giving them the chance to become that star engineer in (hopefully) their own startup in the future.

I enjoy working with smart people, as it gives me the chance to keep learning every day. I enjoy it less when the brilliant people I came to work with turn out to be brilliant jerks . I don’t think it’s an easy decision when you need to choose between a brilliant jerk and ‘just’ a great engineer. It becomes even harder when the brilliant guy, who already knows every bit and byte in your code has a negative effect on the entire team. If you want a great team, I doubt there’s room for that kind.

My bottom line is probably obvious by now – I believe in synergy, in potential and in giving the right people the chance to grow. I’ll take that star team, thank you.

# The Buck Stops Here

Shortly after becoming a manager, most managers realize that one of the advantages in this new situation is that you don’t have to do everything by yourself. Some realize sooner or later that you actually cannot do everything by yourself (others somehow reach the conclusion that you don’t need to do anything by yourself, but that’s a different story). At this point you get to ‘choose’ which kind of a manger you want to be, I guess the scale can be set between micro-management and what I refer to as management by context.

I had a manager once who said that his entire job is to give us context (obviously, in the managing-down direction only. Managers do sideways and upwards management work too, but I’ll concentrate on the down part). This also meant that conflicts and questions in his group shouldn’t reach him, as he, in principle, do not want to give concrete guidance – the solutions should be reached within the group’s scope, relying on and following the provided context. This may sound nice in theory, but practically this meant that it was very hard to reach any decision, mainly because there was no single point in the hierarchy who could and/or would take the responsibility for hard decisions.

It seems to me that this notion of providing context (and effectively nothing more) is the most extreme case of delegation, which got me thinking about the fine line between delegating tasks to achieve more and create synergy, to de-facto delegate core management responsibilities (like, for example, avoiding decision making when decision making is due).

Delegating stuff to your subordinates requires you to trust them in more than one way. You need to believe they are competent, you need to believe they will come to ask for help when they get stuck, but you also need to believe that they will learn and grow from this experience. That last point seems important to me, as delegation is not about the day-to-day tasks of your team, it’s about the day-to-day task you have, which are inherently of the, well, managerial type. So, sharing your tasks with a person reporting to you gives him a chance to prove himself in an area he doesn’t get to experience every day, usually out of his comfort zone and gives you both a chance to increase this assurance that he can take on bigger and bigger roles. However, I tend to think that not every managerial task should be delegated.

I tried to think of a definition for the kind of tasks you should avoid delegating on regular basis (there are cases, of course, where you would make an exception for that, more on this in a moment..), and I think an analogy could be outsourcing. A rule of thumb for outsourcing I learned is that you don’t outsource your core business (one good reason for that is that your core business should hold your competitive advantage), and if we apply this for the manager role – this will mean you generally don’t delegate core management functions. Some of those would probably be more obvious like performance reviews, salary related issues, and in general personal/private issues between you and your reports (by the way, there are organizations and positions which use the ‘second in command’ position to take care of some of the administrative stuff related to personal issues, but I think that’s a spacial case). There are tasks which should be quite easy to delegate (and managers many times do) like departmental budget (internally), daily status reports, etc.

The exception for that rule would probably be in the case of ‘growing’ a replacement. During the initiation time, the person replacing the manager should ideally have the chance to experience all the aspects of the new position while the current manager serves as his mentor/backup/ghost. There could be a longer period before the actual initiation where a couple of candidates get to experience significant parts of the manager’s role as a kind of a long examination of their capabilities (many organizations choose this approach officially).

I, personally, like delegating. One of the main reasons I wanted to become a manager was to be able to create something bigger than I could create by myself. I also like making decisions as a manager since I believe when it comes to your responsibilities you should envision the sign on Harry S. Truman’s desk: “The Buck Stops Here”.

# iPhone development – continued..

So, last time I wrote about what you need to get started with iPhone development. I thought now would be a good time to talk about stuff I encountered along the way, which I guess almost anyone developing for iPhone would encounter eventually.

This time, let me focus on memory management. Objective-C uses reference counting for its memory management, and the version running on the iPhone does not have garbage collection (yes, this is so 90s..). Anyway, this forces the developer to actually think about what is being allocated, when and where. Apple has a guide about Objective-C memory management in its developers’ resources, begin by reading it.. Assuming it’s clear enough, the next thing to do is to actually check your program for leaks (if you’re a beginner, there are leaks – trust me..). Luckily, Apple provides a tool along with its SDK called Leaks (here’s one place where they didn’t think they need to be original..), which tracks your program in runtime (on the actual device, actually, which is pretty cool and also recommended, as the device behaves differently than the simulator in some aspects, and memory is one of those..) and marks places with leaks. The tool is very nice, but in my opinion not the friendliest tool for beginners. One downside is – it can only detect flows you actually went through (obviously), and it’s sometimes hard to determine what’s the actual source of the leak. Still, if there’s a leak during runtime and yo u passed through the leaking flow, this is your best chance to catch it.

One downside I didn’t mention about the Leaks tool and which is not that obvious, is that even when you find a leak, it’s not always obvious why are things behaving the way they are. It so happens that I found a great tool which does static analysis for Objective-C code, and the best thing about it is that when it finds bugs (memory leaks are bugs, duh..), it also explains why is that a bug. The tool is called Clang Static Analyzer and it’s pretty straight forward to use – you download it, extract it, and then use two simple commands:

`/path/to/clang/installation/scan-build xcodebuild`

(This should be executed in your program’s home directory).

Then, once this is done, a report will be generated and the last line in the verbose output of the build will have the report name, then simply execute>

`/path/to/clang/installation/scan-view <report name>`

Which will open a browser window with your report, links to the source files and cool embedded explanations. Once you do the fixes, execute the scan again and check there are no more errors.. note that the default behavior if there are no errors is not to generate a report at all..

So, that’s it for now. More on the fun in iPhone development next time..