People sometimes ask me what I learned when I was working at Apple. The answers depend on the context of the question and who is asking and is certainly too grand to put into a single blog post. However, I wanted to share some top tips learned while I was at Apple that I would want to give to myself if I was just out of school.
Customers can be “Wrong”
You don’t have the perspective of the customer and what you think should be built and what they think should be built can differ. As a young engineer you think you know everything, so when a customer disagrees with your assessment you consider them wrong. You may in fact be correct in your assessment or you may be wrong (more likely) you can’t know for sure since you don’t understand their perspective and they don’t understand yours. I use the term customer loosely because your customer can be many people: They can be your boss, team leader who will be using your code, 3rd party companies, a user out in the world or any of a number of different people. Customers can and will demand things which you don’t agree with. Things which you think make no sense. They can be right or wrong in asking for these things but often times that is what they want you to build.
If your manager at Apple asks you for something crazy you can certainly discuss it with them but if they ultimately want you to build something which you consider crazy then that’s what you need to do. Gaining experience is realizing that you won’t always agree with what your customer wants but that the person with the money makes the decisions at the end of the day when there are disagreements. I see far too many engineers debating with “customers” whether they are wrong or not on a direction. Certainly it is good to bring up the drawbacks with an approach. However, if you bring up the drawbacks and the customer still decides to proceed, it is your job to implement that vision as best you can. You don’t make the final decisions because you aren’t the one with the money. Perhaps one day you have the money and can make the decisions and that’s fine but that isn’t today.
Go With The Flow
The best way I can explain this topic is with an example: One of the early tasks that I very clearly remember from my time at Apple was almost the first task I was assigned. I was working on a piece of functionality in Mac OS X related to print drivers. We were making a change in the operating system that was going to force a small number of printer manufactures to update their driver so it worked with the new version of Mac OS X. The old driver wasn’t going to work anymore and users were going to have to upgrade to a new version of the printer driver. This was a preventable situation if Apple expended extra effort to avoid breaking the printer manufacturers but Apple wasn’t going to do this. The task I was assigned early on was building a workaround for this problem for the manufacturers and sending out the code they would need to include in their new driver. However, I was furious that this code wasn’t just going to be included in the operating system by default to avoid this problem. It was the only task I was assigned and I could only see this problem and nothing else and of course considering only this and nothing else the best thing to do was to include this piece of code in the operating system. I had already written that version of the code of course.
I was wrong though, very wrong. I didn’t have perspective of the entire operating system and the entire Mac OS X project. Of course it would be better to not break this small set of printers and force users to upgrade however what I didn’t see was the bigger picture. Apple was pressing out the release of Mac OS X out the door we couldn’t include small changes that weren’t important. To maintain quality you don’t want to include lost of new features or changes towards the end as you are going through testing stages. There were thousands of people that worked on Mac OS X at that time and even more people that wanted to include a new feature or code change. Towards the end of any project you have to say no to maintain quality because if you are making code changes just before a project goes out the door you are asking for disaster. At the time I had no concept of this and thought there was something wrong in the world. Because I didn’t see the bigger picture I was just plain wrong.
So my early advice, and something you learn with time, is everything you are working on seems like the most important thing in the world. Just as I did with the printer fix. However, your task is in the grand scheme of things is probably not critical at all. Later on as I was more experienced I did work on things that were critically important and they did get in very very late, but those were important fixes that needed to be in, in the grand scheme of things. Not just in my opinion. Without that wider perspective you can’t see that and young engineers do not have perspective. As a young engineer you will not have the perspective of the entire business and possibly not even the entire project you are working on and because of that you will think things are important which aren’t that important but you have no way of judging. So my advise is go with the flow. As you become more seasoned and able to judge what is important and you will pick and choose battles but for now the best thing you can do is go with flow. Certainly bring it up with someone more senior if you feel strongly about it, to make sure they are aware of it. But if they don’t think it is important then accept it and go with the flow.
Quality is Important
I remember having discussions of how important quality is and how to tackle a certain problem. Certainly you may be constrained by time and other factors on a project that prevent you from creating the perfect solution. However, always do your best to create the best quality project you can. You will thank yourself for this as will your customers.
Nice to Have Your Own Island
My Manager at Apple started with Apple back in 1984 and his first project was Apple Lisa. He stayed with Apple for many years doing quite well for himself over time. In fact after doing well he decided he wanted to buy his own Island in the Pacific. That would be an island with electricity, house and all the amenities but would just be for him and his family. He decided to buy his own island and did so even outbidding a Saudi Prince who was bidding on the same island. He lives on that island now making trips to the valley as he desires. So while not a lesson for everyone, a lesson I learned is, it is nice to have your own island and if you do things right such things are possible.
Hard Work Pays Off
I didn’t care in school that it would take an extra four hours to do something right and the grade might not reflect the four extra hours put in. I didn’t do calculations of grade/time ratio to determine if I should put extra work in or watch TV. I wanted to do it right and I wasn’t afraid of hard work even if it was extra work. This should be your philosophy if you want to succeed in the long run. Do the hard work and don’t be afraid to work even harder. They didn’t tell me until after I had been at Apple for a year but they had literally hired 18 people in the position before me. The longest person had lasted was six months. All 18 had been fired or let go for one reason or another but I stuck around. In school and since I have seen young and older engineers trying to avoid hard work. This is not the path to success. To take the short cut because someone isn’t looking or you think you will get away with it will only lead to disaster in the long run. You may get away with it in the short term maybe even a few times. But in time, no matter what you do, you will be found out one way or another and then the consequences will be paid. It just may take longer in some places than others but you will be weeded out because you don’t produce value. Mark my words. Anyone who produces value will be valued and over time rewarded. But certainly no matter where you are if you don’t produce value then eventually you will lose. So don’t avoid the hard work, go towards it and get it done. That is the sign of a true engineer and a professional.
Hard work and the right attitude can also lead to your own island (or equivalent for you) if you do it right. When that happens you can be the “crazy” customer who is “wrong” that wants their house on the island designed in a certain way.Chad Jones
Chad is the CEO and founder at Push and was a former Apple Engineer before returning to Saskatchewan to revolutionize the mobile development world. Chad is passionate about creating efficient, well-designed software. Chad knows that people care about their mobile experience and Push is here to give them that great experience.
Push Interactions is a custom mobile app development company. If you have any app idea, we can help you develop an app perfectly suited for your users. Contact us today for a free consultation. CONTACT US