Quora thread on “What are some things you wish you knew when you started programming?” is a goldmine of wisdom. Irrelevant of how experienced you – whether you’ve been programming for decades or just thinking about a new career path, which programming languages and technology stacks you use, whether you’ve completed format education or taught yourself everything you know, I’m sure you’ll find valuable lessons and food for thought in there.
David Walsh shares some thoughts on an impostor syndrome. I’m sure anyone in the tech industry can relate. I certainly do.
“Impostor” is a powerful word but that’s how I have felt during all of my career as a professional web developer. I feel like I’ve learned every day of the ride but I feel like I’m way behind. I feel like people see me as something of an expert where I see myself as an accident waiting to happen. I’m a complete impostor. A fraud.
Apart from the honesty of his feelings, I like his ways of snapping out of it. They do work for me too:
- Look at your (hopefully decent) employment history and know that, on a basic level, you’re much more wanted than you’re wanted gone
- Log onto the IRC channel of a skill you feel comfortable with and answer questions of those asking
- Realize that people who consider themselves “experts”, and don’t go through waves of self doubt, are idiots that are so arrogant to not know what they don’t know
- Remember the last time a non-developer friend asked you the most basic of computer-related questions
- BLOG! The worst thing that can happen is someone corrects you and you learn something out of it
- Review your code and find little nits to fix
One other thing that helps me, is this bit by Joe Rogan:
He talks more generically about life, but I think it’s equally applicable to technology knowledge as well.
Amitj Aggarwal, former Staff Engineer at Google (2008-2012), has collected a whole bunch of data in regards to engineers salaries, in USA and worldwide. His points seem to be overly optimistic at times, but I don’t have any links handy to contradict his research.
Here are a few points to get you started:
- Zoho, Salesforce pay 40% more than Oracle, Cisco, GE!!!
- Top 7% or so engineers at Netflix, Amazon, Google, Facebook are paid more than $1.4M per year. Next 10% make $700K on average.
- Facebook has lost relevance to Slack, LinkedIn, Snapchat, Pinterest and Quora. If you are working at Facebook ask for a 50% raise else move to a startup.
- Oracle is loosing to cloud startups. If you are working at Oracle ask for a 60% raise else move to a startup.
- ENGINEERS DO NOT WASTE MONEY ON AN MBA. You will make 2X more on average as an engineer.
- Tableau, Splunk, Slack, Airbnb, Quora, Twitter, Facebook, Google pay more than $320K salary to their top hires. Definitely interview at these fine places. Uber top engineer salaries are $190-340K per year.
- Starting salaries for fresh software engineering graduates is now $130K-160K. Ask shamelessly. For the best ones its ~$180K.
- Apple pays 60% more than Samsung.
Software Engineering Tips shares some tips on how to figure out if you are a bad programmer, and how to remedy that.
Signs that you’re a bad programmer
- Inability to reason about code
- Poor understanding of the language’s programming model
- Deficient research skills / Chronically poor knowledge of the platform’s features
- Inability to comprehend pointers
- Difficulty seeing through recursion
- Distrust of code
If you are not a bad programmer, check if you are mediocre one.
Signs that you are a mediocre programmer
- Inability to think in sets
- Lack of critical thinking
- Pinball Programming
- Unfamiliar with the principles of security
- Code is a mess
And, finally, here are some signs that you shouldn’t be a programmer.
Signs that you shouldn’t be a programmer
- Inability to determine the order of program execution
- Insufficient ability to think abstractly
- Collyer Brothers syndrome
- Dysfunctional sense of causality
- Indifference to outcomes
The article also suggests some alternative career paths for you.
“The True Reason Behind The 40-Hour Work Week & Why We Are Economic Slaves” doesn’t really say anything new, but it explains things nice and simple.
We automatically accept a 40-hour workweek with meager hourly pay as normal, even though many work overtime and still struggle to survive. There are also those who make enough to live comfortably but are unable to request less hours—you either work 40 hours a week, or you don’t get to work at all. We submit when told what to wear, when we have to arrive and depart, when we’re allowed to eat, and even when we’re allowed to use the restroom. How is it we have come to allow this?
The 40-hour-work week came about during the Industrial Revolution in Britain when at one point workers were putting in 10 to 16 hour days and began to protest. Working situations for Americans began to worsen as well, and by 1836, labor movement publications were also calling for a 40-hour workweek. Citizens in both situations were so overworked, an eight-hour day was easily accepted. This system is unnecessary now, if it ever was, but we still accept it due to the effects of our capitalist society.
It goes over the relationship of inflation, debt and consumerism with a few historical references. Good reading for anybody wondering why the paycheck-to-paycheck life cycle is difficult to change, no matter what’s the size of the paycheck.
In an office setting, I see power and influence gather around…
- The person with the newest, coolest and/or most expensive clothing
- The person with the larger corner office
- The person with the most assistants
- The person with the most impressive sounding title
- The person with the closest parking space
- The oldest, richest, whitest males
- The person who’s allowed to create or interrupt meetings
- The person with the most impressive social and public-speaking skills
- The person who uses their power to get what they want
In a distributed organization, I see power and influence gather around…
- The person who produces output and solutions that exceed expectations
- The person who can connect deeply with colleagues over a distance
- The person who can effectively and concisely articulate their own views and ideas
- The person who helps their coworkers be the best versions of themselves
- The person generous with their understanding of how to navigate the organization’s processes and culture
- The person who can give voice to unrecognized or unspoken truths
- The person who learns fastest from their mistakes
- The person who uses their power to empower others
It’s of course not fair to generalize this way. There are healthy traditional organizations where appearances are not necessarily the basis for power. There are probably unhealthy distributed organizations where power centers around the appearance of lots of activity that produces few good outcomes. But my experience so far is that a distributed organizational structure inherently facilitates an experience of power, empowerment and leadership that is better for the people in it, and for the work they are doing together.
I don’t have much experience working for a distributed organization, but judging by many Open Source projects, which are, in essence, distributed organizations, I’m inclined to agree with the above observations. I wouldn’t be able to put in words so well though.
I’ve seen this chart before, but completely forgot where it was from. Tried to find it a couple of times in a hurry of a conversation, but couldn’t. Thanks to this SysAdvent blog post, I now have it permanently engraved into the archives of my blog.
xkcd figured out how long can you work on making a routine task more efficient before you’re spending more time than you save. The crossing of how much time you shave off and how often you do the task gets progressively less obvious when move from the top left corner of this char to the bottom right corner.
SysAdvent runs a blog post about Operations (in IT sense of a word), explaining what the department (hopefully it’s a department and not a single guy who doesn’t remember the meaning of the word “sleep”) does, and how the job complexity silently escalates with time.
An operations team, almost by definition, focuses on the steady-state “run” of whatever that team is responsible for … well, operating. This could be an electrical plant, an HR department, or an IT operations team; anything which needs to function day-in and day-out, reliably and without fuss. Those things the rest of us assume “just work”.
But just because we don’t notice doesn’t mean there isn’t anything happening. Much like an iceberg, where 90% of its mass sits below the waterline, nobody outside the team is aware of what the team actually does in order to make sure everything “just works”.
Anybody who’s been involved in Operations, at some point goes through this bit:
We can see how Oscar’s responsibilities grew over just two years. At first, it was just 6–8 laptops, office wifi, and a third-party office solution. Then it’s a cobbled-together server. Then development environments. Within a year, it’s 20 laptops, two application environments in the cloud, monitoring, alerting, and backups. After another 12 months, it’s a dozen third-party services, 40 laptops, 2 team members, offboarding processes, and monthly security audits.
Over beers one evening, Oscar makes the comment to a teammate that even he didn’t understand just how profoundly the company depended on the operations team; how much impact his work had on everyone else’s ability to do their jobs.
This blog post actually goes well with the one I am planning to write shortly about software features being like babies. Stay tuned.