The first step of troubleshooting is not finding someone to blame for the problem. It is also not Googling wildly and moaning about how no one has ever encountered your exact problem. Troubleshooting is not a gift or a talent, it is a learned technique, and anyone can learn it.
When you troubleshoot:
- Define the problem
- Isolate the problem
- Form a hypothesis
- Test your hypothesis
- Repeat until problem is solved, or proven unsolvable
The last point is very important. There are only 2 types of problems:
- Those you can solve
- Those you can’t
Long before you give up and declare a problem unsolvable, at least make sure you’ve tried everything you can think of. Google is not a replacement for the scientific method.
I have tried, and tried, and tried to teach web security to web developers, but I never felt like I was doing a good job. Today a better approach occurred to me: Have the developer write a simple application with all of the OWASP Top 10 vulnerabilities.
The are engineers who manage their career by jumping from company to company about every year or so. I call these types of engineers “Ronin” (Masterless Samurai) as they have given up the idea that they will work for the same company for the rest of their lives, and instead wonder the job market looking for new challenges and more compensation. Loyalty to a particular company is completely missing, as in their eyes the opposite is true. “If a company can lay off an employee at any time,” the logic goes, “then I can leave at anytime I wish.”
If you over specialize you will die a slow and painful death. No matter how much money you’re making being the soul living expert of a legacy system or technology, it will catch up to you when you inevitably have to switch jobs. The flip side is that if you over generalize, you won’t have any marketable skill, as no one will know what you’re good at and therefore how to use you. The best approach is to pick a specific area you’re passionate about, and become a generalist with a high degree of proficiency in all the relevant skills.
Believing that your programming language in anyway defines you is asinine. I can only assume those who declare themselves a (whatever) programmer have the same type of character flaw that leads people to believe that your are the car you drive or the clothes you wear.
There’s a bad habit among engineers of judging their peers by their recall of rarely-used information. For instance, if an engineer didn’t know what “$” meant in a regular expression, the assumption would be that the engineer – in general – was a bad engineer. I have done this (and may still do this) and have seen it consistently my entire career.
You can only propose a solution to a problem if you have knowledge of how to solve the problem. This is a indisputable fact. If you have lots of knowledge of how to solve a problem, you can propose lots of solutions. However, if your knowledge is limited…
For a while, we didn’t have to worry about performance. Hardware was fast and cheap, and the network was more than fast enough. However, with the rise of mobile devices, we now have to start worrying about performance again.
I often get the feeling that quality would be higher if there were no QA people. My thought is that without QA, 100% of the accountability falls on the engineer to find and fix bugs. Additionally, since many engineers don’t or won’t manually test their work thoroughly, being accountable for finding and fixing their own bugs puts more pressure on the engineer to write automated tests.
This, of course, is dependent entirely on how much the engineer cares about there being bugs in the system. Most engineers don’t care, using the rational that bugs are simply a by-product of developing software, and having a certain number of bugs should be acceptable. Furthermore, some bugs are minor, and should be de-prioritized in favor of high priority bugs, so really there are some bugs that will never be fixed by virtue of responsible triage based on business priority.
These types of engineers are typically lazy bastards and are unaffected by the presence of QA – they will do whatever they feel like, largely because they can get away with it. If you work with these types of engineers just figure out what they did to get such a sweet deal, and get career tips from them.
The engineers who benefit most from not having QA are those who are not lazy bastards. These are engineers who take pride in their work, and don’t want any bugs in their system, but who make honest mistakes. Without QA, these engineers get better.
Your reputation is what people say about you behind your back. While you may be able to influence what people say about you, you cannot control what is said. Your reputation is subject to gossip, rumor, and office politics, and once damaged is difficult to repair. Establishing and maintaining a good reputation is essential to having a successful career, but few people are aware of their reputation, much less how their actions can positively or negatively affect it.
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
A unified team is more effective at accomplishing objectives than a group of loosely organized individuals. When a company forms a team, they select a manager to be in charge, and make the team report to that manager. The issue with this approach is that only some types of managers are capable of building a group of individuals into a team.
When I first started working exclusively as a software engineer, people who knew me as a designer were convinced I had gone mad: “Who wouldn’t want to do design?” Short answer: Me. I did design for other people for the first 7 years of my career, and let me tell you – it sucked. It sucked because all of my effort and inspiration would go into a design, only to have it reduced to, “Can you make it blue instead of brown – my wife likes blue.” That was an actual, real statement for my last design client. It wasn’t that this was the first time I had received feedback on my designs (and this was by no stretch of imagination the worst feedback I have every gotten), but it was the last straw. It would be years before I opened Photoshop and Illustrator again.
Back in 1998, I made my first real, publicly accessible website. It was NeilsMachine.com (long since taken down), and it was a “blog” before blogs were blogs. I talked about nothing at all, because I really had nothing to say. Shortly after my NeilsMachine days, I got caught up in my professional career and let all my personal sites languish and die. When I did my own consultancy, I never managed to get a website up, which always bothered me. The challenge, I found, is that when would I have time to do my own website when I was building sites for others? I made several good stabs at it – including one design that to this day is still very cool – but they never saw the light of day.