My comment was a sort of provocation, but I see that some people seem to agree with it. It makes me a bit sad, but unfortunately sometimes it's pretty hard to change things - if at all!
The other comments are all relevant and very good, but they seem to overlook one important aspect: the company's attitude. What all those comments have in common is that they assume things work according to Tom DeMarco's book Peopleware. I have learnt on my own experience that they don't. I have had the chance to work with 1)poisonous, 2)negative, 3)defensive (see the psychological meaning), and 4)offensive (... no psychology needed here) senior developers. Some nicer/more experienced than others, no doubts, sometimes also due to the lack of communication skills (English is not everyone's first language, and I do understand it). However, these ones were senior due to the number of years spent in the company OR their age. That's why I think that the companies that value someone's skills (I like to see them like technical skills, IQ and EQ) for their promotions are the minority.
Yeah, as I read many comments in this thread I'm left thinking that either these people are very naive or I'm severely jaded (or both). But the notion of work hard and you'll be rewarded is kind of silly when you're working as an engineer at MegaCorp.
I think if you're in a small company things could be different.
I used to work for MegaCorp and I was only a number there. In that company you could become "senior" only if you was grey (literally) or know somebody higher in the structure. That was one of reasons I left to join startup.
> What all those comments have in common is that they assume things work according to Tom DeMarco's book Peopleware.
This is a funny comment, since he keeps repeating through the entire book phrases that sound like "you probably won't be able to get this for your team", "you likely never seen it anywhere, but...", "when doing our research, we've seen this. You might doubt it, but trust me, this exist on some places."
> This is a funny comment, since he keeps repeating through the entire book phrases that sound like ...
Yeah, I know. Of course I meant "things work according to the advises given by the book ..." or something like that. I read the book, and everybody agrees that "it's a great book, but in reality...".
> So, just eat healthy, do some sports, and get older.
On the contrary, smoke as many cigarettes as you can in a day, have a whole bottle of whiskey every day, only eat fried foods, and sleep on your face. Within just a few months, you should have the look of seniority! It's all about finding shortcuts up the corporate ladder.
Depends on what kind of dev you are talking about. In a consulting shop (enterprise or web dev or advertising)? Big company (software, hardware or where software dev is an expense)? Game company? Silicon Valley startup?
Senior devs in each of these types of companies have some skills in common and some that are particular.
The common ones, in my opinion:
* Ability to communicate with non technical folks
* Ability to estimate relatively accurately
* Willingness to do grunt work to raise team productivity
* Ability to work self sufficiently, own a big chunk of work, possibly leading small team
* Knowing when to raise an issue to higher ups
* Willingness and ability to mentor folks more junior
* Knowledge of the general software landscape for your domain, including what is buyable vs requires building
How to acquire?
* Seek mentors
* Always be learning
* Seek out folks outside of your department and learn what problems they face
* Attend conferences, technical meetups, or other online learning opportunities
* Help out
* Focus on solving problems and not on being right
Disclaimer: I have spent some time in larger orgs, but mostly as a contractor so my advice may not be applicable for those.
Willingness to do grunt work is a fast track to becoming a manager who says "I haven't coded in years".
No good deed goes unpunished. When you step up to be a team player and do that grunt work, you open yourself up to getting more and more of it. Next thing you know you have to stand up for yourself or become a door mat.
The trick is to not volunteer for recurring work. My stance is I will volunteer for 1 thing per week which is defined, ad-hoc, and <5 hours. The bonus to this is your far less likely to be forced into endless time sinks as you have team credibility to say no.
If you're in an environment where rolling up one's sleeves and taking on the grunt work leads so quickly to negative reinforcement loops, in the way you describe... then that's a sure sign that you've found yourself in the wrong environment.
In healthy environments (and yes, they do exists) good deeds are actually rewarded, not punished.
I don't think it's so black and white. In this case, the "punishment" isn't literal. It simply comes in the form of more grunt work, which people trust you with because you have taken it on before and did a good job with it. You may actually be rewarded too when the annual review comes, if you know how to spin it.
Furthermore, grunt work can be an excellent opportunity to shine. For example, you can figure out a way to automate it so that the next person who works on it (which may be you again) has to spend only a fraction of the time on it. Things like running reports or generating documents tend to lend themselves really well to automation, and a little programming ability can take you a long way.
So yeah... think twice before turning away grunt work, even if you believe that you may be given more of it in the future if you agree to take it on now.
These are all very good points, coming from someone in a agency/consulting shop. Big things I find are being able to communicate effectively with non-technical folks, budget accurately, and knowing when to ask for help vs. hammering something out.
Do you have any suggestions for becoming more accurate when it comes to estimating effort?
I find that my estimates are generally all over the place and multiple attempts at predicting how much time it will take to complete an assignment don't converge as time passes. Even though I had seen and been given diverse tasks over the course of my work, I can not really pick a previous item of similar magnitude for reference.
I'm not terribly good at this, but I've had some luck taking the first answer that pops to mind and multiplying it by three. It's a crude method, but over time, it has worked well for me.
This usually works OK in practice for small or medium projects, but as Brooks points out in the Mythical Man Month, you are also tripling your estimation error. This can cause a lot of divergence for longer projects.
I'm a chronic under-estimator. So, whenever we're in grooming or sprint planning, I make it a habit to ask the other members of the team if the size/hours make sense, or are straight out of "Al's world".
In those occasions where I'm asked to provide a WAG to an executive or salesperson, I always multiply my first thought by 150-200%. Maybe even 300% if there's an external stakeholder (3rd party integration, something for a specific client, etc).
Generally, I see "senior" as mid-career, kind of based on how Google does levels. (Engineering is basically "levels" 3-9, you get the "Senior" title at 5, so there is still quite a bit of career growth left after "Senior".)
Some things that you would want to start focusing on:
1) Figuring out what projects come next, and designing them.
2) Figuring out what your team wants to work on, so you can shape future projects to be exciting to them. (We always have an infinite number of things to do, so you might as well pick the things that are most interesting!)
3) Doing detailed designs, so that work can be parcelled out to people that are gaining experience.
As you might guess, at this point you are doing more than working alone or working on engineering tasks that someone else defined. You are defining the tasks, and are starting to define the bigger projects.
Your individual contributions should be setting the standards for others that work with you. Write that extra test, clean up that documentation, don't launch a new service without monitoring. What you value will become what your team values, by your example.
How to get to this point? Hopefully the more senior members of your team are setting you up for success; allowing you to do some of these tasks until you're good enough to do them without supervision.
Domain knowledge about the business activities that your software is supporting is powerful. Do you know why your users want what they want? Can you suggest a better approach to solve their problem, based on your deep knowledge of business needs? Do you know the impact of requested changes on other parts of the business. This, of course, is very specific to a company/industry.
Knowledge of accounting principles is often helpful for in-house developers.
A senior developer varies between different companies. In some companies, if you are a senior developer, you start getting more client facing roles. So your communication skills becomes more crucial. In other companies, you gain a mentor kind of role where you assist your team in designing and developing projects accordingly.
To build on the suggestions other people are making, I would say that one thing I look for in the transition from to "senior" is the ability to make the people around you better. At the junior/entry level, a lot of your focus is about consistent delivery for yourself. As you move up the ranks, its about making you and your team better.
That could be removing roadblocks by flushing out designs and specs like other people have mentioned, or finding better processes and practices to make the team more effective. Of course, there is also the proper introduction of new technology or techniques to raise the company forward as well.
The ability to walk in somebody else's shoes for a while makes you a better developer. Why?
* You acquire the habit of imagining what it's like to use the stuff you develop.
* You have a feel for the daily experience of your colleagues, suppliers, executives and other stakeholders.
These things give you the sort of spidey-sense that lets you function independently. They also give you the ability to enlist other people to get things done.
How can you learn empathy? Like any skill, it takes practice.
--Listen to strangers. The question "what are you doing this afternoon" asked at lunch will usually get an interesting response. Interject "wow" - like sounds to keep them talking.
--Seek opportunities to meet end-users of your stuff. (Ask sales people to take you along on calls if that's appropriate). Observe their work.
--Ask your executives and project managers questions like, "what keeps you awake at night?" And listen to the answers.
--Teach. It doesn't matter whether you teach short courses or get a night job as an adjunct professor at your local CoCo. Your interactions with students will help develop your empathy.
People love to talk about themselves. You can take advantage of that to practice empathy.
One of my favorite tips from the book that's stuck with me in the 10+ years since I've read it is the immediate breakthrough you'll have with someone if you pronounce their name correctly when you meet them for the first time, particularly if their name is uncommon to your culture. In the author's case, I believe it was a Greek business partner whose name other English speakers had anglicized down to "Nick." When the author pronounced the other man's name fully, the other man welled up and replied that no one had tried that in decades. I haven't ever had a response quite so extremely positive, but I have experienced sparks of surprised excitement from new coworkers with, for example, Polish and Indian names when I've taken the time to think about or learn how their names are more accurately pronounced.
I've found "what'd you get up to this weekend" to be a great conversation starter because most people have done at least one fun thing over the weekend.
You don't have to talk about things that other people think are fun. The point is to bring up something that can get you excited and animated. If what you call "work" does that for you, then I'd love to hear about it.
That is fine. Talk about that. The point isn't to tell someone what is exciting, it is about making connections. Perhaps you read a research paper on a topic the other person has an interest in. Perhaps you contributed to a project they use in their spare time, or could use on a side project.
If I'd asked you that question, and this was your answer, I'd probably have asked you all about the papers you'd been reading, what kinds of issues you ran into reviewing other people's source code, and the what and why of the projects you were improving. I'm sure I'm not alone in that.
I empathize and find your weekend activities relatable. Answer a question about your weekends with that and you might just find someone else who spends their free time "being productive". :-)
You might like to hear about such things, but most people only want to hear about weekend activities they consider "fun" (e.g., going out drinking) or "normal" (e.g., doing stuff with the kids). If you say you spent the weekend learning something new, most people will act like you're boring and perhaps even make nasty comments like "you must be fun at parties" (like someone in this thread did).
Talking about normal/fun activities like you described are safe conversation topics that you can use with nearly anyone. If you don't know much about someone, then these topics are easy ways to get a conversation going and learn more about each other. Once you do know someone a bit better, you can tailor your conversations to more specific interests that you both share. A work colleague would probably be interested in talking about patches you submitted to open source projects or research papers that you read even though 99% of the general public probably wouldn't be interested.
I don't know exactly why the other commenter said "you must be fun at parties," but I'd imagine it's because the parent commenter deflected from talking about things he actually wanted to talk about. Being fun doesn't have much to do with the content of what you talk about. It has more to do with you showing genuine interest and excitement for the things you do. If you don't like watching movies or playing video games, then it's very difficult to have a fun conversation about those things. CiPHPerCoder listed four things he enjoys doing over his weekends. Those topics are definitely not mainstream, but they do overlap with my interests. I would love to have a conversation about those things with him because it also adds to the variety of conversations I get to have.
> CiPHPerCoder listed four things he enjoys doing over his weekends. I would love to have a conversation about those things with him because it also adds to the variety of conversations I get to have.
Sorry, would have responded sooner but HN's rate-limits kicked in.
> If you don't like watching movies or playing video games, then it's very difficult to have a fun conversation about those things.
I do enjoy those activities, but I accepted a lot of responsibility (especially with making secure PHP code-- a feat some infosec folks claim is inherently impossible) and intend to finish what I started. That means missing out on a lot of great movies (Warcraft, Zootopia) and video games (OverWatch) that my friends are all able to enjoy.
Ultimately, I believe the work I'm doing today will make a difference tomorrow. Whether I'll be able to capture any of that value for myself remains to be seen.
I hear where you're coming from. I used to feel this way, and I sometimes catch myself falling back into this thought pattern.
But now I try to be as open as is practically reasonable about my interests and hobbies. You'd be surprised how receptive some people can be. And those who react negatively are filtering themselves out of further interaction.
I don't think it's an all or nothing proposition. If you don't know someone very well then it's likely they are just looking for small talk. In that case whether or not they are interested in the topic, they aren't looking for something that is going to turn into a deep conversation at that moment. There are ways to probe for this though, just give a high-level summary like "just did some work on my side project" or similar where you give them an opening to ask a question and go deeper. This gives an easy out to end a conversation gracefully; if an actual grownup gives a snarky response like "you must be fun at parties", that person has way worse social skills then they think they do, and in all likelihood has some pretty severe security issues.
I have a coworker & friend who baits me into conversations like these. One time at lunch I realized near the end that I had monopolized most of the conversation. I'm the class introvert who by nature doesn't say much but rambles given the right topic. So I started to apologize and he replied: "Jonathan, that's why I asked you the question."
Not all people are looking for their own words echoed back to them. Like the OP who suggested this advice in the beginning, some people are really interested in seeing things from different viewpoints.
Being somewhat similar, I sympathize. I just tell them that I spent the time relaxing all weekend (regardless of what I actually did) and it seems to satisfy people.
(In spite of the stereotype, I'm always surprised to see how few genuine "introverted coders" there actually are in the industry and how unsympathetic the rest are.)
More people than you think follow this advice, which just leaves us with misunderstood anonymous social interactions.
It's OK if you don't want to spend the time to explain the nuance of your personal existence, but do understand that there is nuance in everyones existence. Expecting that the other person you are talking to "won't get it" is just blatant egotism.
Taking time to express what's important to you, and why, can be a very constructive thing for those who want to listen. The OP advocates empathy, and this is where it comes from. In my personal pursuit of empathy, I've had to filter out responses from people like you, and try to see beyond the untruthful statements in an attempt to understand what they are really saying. Shyness is one thing, but a pattern of lies and deceit are indicative of fundamental imbalance.
If you're having a hard time expressing why it's important to you, consider introspection; is it really important to you? If you don't come away from a day, or week, or weekend with something to tout when prompted, I dare say "you're doing it wrong".
I'm certainly not saying that I have something to be proud of every day, but that I'm honest with myself when I don't, and will express to others that I likely accomplished less than them in a given period. No lies necessary, and the other humans around you are given an opportunity to see your similarities, instead of some false iron gate of awesomeness.
I am not sure you have a lot of empathy if you automatically assume people want to be asked that question. I hate it if colleagues without kids ask me about my weekend because I believe that the joy of fatherhood breeds extremely boring stories for those who don't share it. I just don't want to feel lame telling you about how cute my daughters were.
Or if I am bustling with joy because the wife and I managed to sneak in an evening of kinky sex between bringing the kids to bed and work on monday. THAT's what I am thinking about and THAT's not what I want to tell you. So I invent some stupid story just so you are satisfied.
It's OK if colleagues which I know well and with whom I have a kind of bond ask things like that. But not as a conversation starter or to create such a bond.
And the list of people who cannot stand questions like that goes on: those with depression for whom every weekend is just a period of grayness, those with social anxiety...
"That question" need not be singled out as an outlier; what we're talking about is casual conversation.
Inventing a story, rather than truthfully explaining that you "enjoyed spending time with your wife and daughters" sounds sick to me.
You have a bond with everyone else already: we are humans. There is no prerequisite.
As someone who identifies with both depression/anxiety and positivity toward my accomplishments, in addition to a definite introversion, I reiterate my last paragraph from above: stop lying to yourself and others. If you had a simple weekend, where is the shame in admitting it?
If it was bad enough that you can't admit it, use that to fuel your development instead of pacifying it.
Well, for me it's not usually work, but it's still "work". It's fixing faucets, and trimming bushes, and cleaning out rain gutters, and keeping cars maintained. Much of a weekend is what I need to do, not what I want to do.
When I'm asking this to the junior engineers on the team I'm usually trying to tease out what they think is fun or what their non-work interests are. I have many of them that are over engaging at work (they're achievers) or having trouble adjusting to a new city without as many of the forced social situations of college. Me asking this is to get to know more about you so I can a) talk with you about non-work things, b) learn a bit more about you, c) offer advice when I see self imposed burn out approaching.
If all you do is work work then I think you should probbably re-adjust a bit on the weekends or you'll narrow focus too or you're just working too hard. If you're doing side projects, I'm an engineer too, I LOVE to hear about that stuff. It's why I read hackaday and hacker news.
Quite right. In a one-on-one conversation, I know how to conduct myself to make it less awkward for the other person, but I still feel like I'm lying by omission when I answer questions like that.
Then don't answer it in the traditional fashion: turn it into a joke. "What did I do this weekend?" "I gave birth to a live baby zebra." It'll make people laugh (or at least smile), they'll think well of you and you never actually do tell them what you did for the weekend.
Another tactic is to say "not much, what about you?" People love talking about themselves.
The "weekend" question is a good one. But: think about this. It implicitly carries your own agenda, but doesn't reveal it.
What do I mean? The person answering probably wonders whether his weekend adventures will compare favorably with yours. "I went to Tahoe!" "I caught a pop fly ball in Candlestick Park!" "I stayed home and binge-watched Gilligans Island." "Loser!"
Asking about the future is less competitive. Answers can range from "I'm going over to Sand Hill Road to get my investors to sign off on my IPO papers" to "StoopidCo sends this corrupt XML feed...I have to figure out how to ingest it" to "I'm going home sick, I feel terrible." In each case the answer is about the person speaking, not about you the questioner.
But devs are perfect and special snowflakes who should be deferred to in every context. The users should just do what we put in the nonexistent documentation or figure it out on their own because the software is perfect amirite?
Under the empathy umbrella, I'd add patience. Play the long game. Give people time to come around, catch up. Earn the respect and trust of the people around you.
Great great post. Thanks for summarizing that so eloquently - I'll be keeping a copy of this comment around as a list of things to practice and continue practicing.
I've come to believe that understanding what empathy is and how to develop it is easily one of the most important skills we have in all stages of life, and the lack of it is one of the most common reefs that people crash on in adulthood.
You really see the effects in the tech industry, as many of us were drawn to this line of work when we were undersocialized introverts in our teens and 20's. I know I was. I really resented social pressure in all forms, and was always pissed off that everyone else didn't see me for the genius that I thought I was at that age (which I was not, of course, but that belief was the only thing that got me out of bed some mornings). I loved the idea of a job where all that mattered were my technical skills, and never had to interact with other people, not realizing that any engineering job worth having would not fall into this category, if such jobs even existed.
I frequently see people get angry in forums when they think people are arguing with them based on the tone or wording of what they said rather than the content of their post. I frequently see people make comments in forums along the lines of, "99.9% of humanity is just too freaking sensitive and I refuse to change myself to adapt to them." More topically, you will occasionally see politicians or other public figures brush off outrage against some mind-numbingly hateful or stupid remark with excuses like, "I don't have time for political correctness", as if their lack of PC-approved verbiage was the reason people got angry. All of these things are indicators of people who not only don't have empathy but don't even realize what it is. They think empathy is like sympathy, or some other warm and fuzzy lets-share-our-feelings thing that they don't think they need to understand.
But really empathy is just the ability to have at least a shred of intuition for how things look from other people's perspectives. I think of it more as a neurological function than anything else, another high level input that our brains synthesize for us from lots of low level activity that we're not aware of, not unlike sight or hearing. It's a prerequisite for effectively communicating things to other people, and it becomes even more important when the people you are communicating with are predisposed to disagree with whatever you're saying. It's not schmoozing, it's not knowing how to sugar-coat what you say so as to not offend people (although that's often a pleasant side-effect in touchy situations!), it has nothing to do with political correctness, it's not even a social skill- it's literally just having the tiniest sense of how you come across to other people so you can communicate as effectively as possible. It also makes it much, much easier to design software that actually solves problems for other people, and to arrive at the best possible compromises in personal and business dealings. It also will aid in your awareness of problems that might not matter to you, but matter a lot to the people whose problems you want to solve.
All the 'soft skills' that other commenters have mentioned are definitely useful things to have but they're things to learn when you want to stop coding soon and move in to a more management oriented role. If you still want to write code as a senior, learn to write better code.
In my opinion a senior developer is someone who writes software that can be maintained without their presence. That means less clever, impressive code and more boring code that's simple and straightforward to understand that just does what it's supposed to do. It means reproducible deployments. It means tests which are up-to-date and working. It means everything is documented in a way that a junior developer, or even someone non-technical, can get value from.
Frankly, none.
Everywhere I know of the position of senior dev is defined solely by your technical expierence, and the screening in job interviews for non-technical skills are the same for junior or senior dev positions.
Perhaps a better question is what non-technical skills do I need to work well in a team (as a senior or junior dev), every developer needs to know how to listen to people with different expierence and teach others about his own, whether he's junior or senior.
That's too bad. The senior devs I know are generally good with people: Making them better, working out differences, getting people on-board with solutions, helping one-on-one with things like code reviews and debugging sessions, writing design documents, finding and fixing bugs that aren't theirs. The list is endless. Oh, and they write code, too, generally lots of it.
I generally find that less experienced devs are the ones writing lots of code. Personally I think more and write less of it (and it usually works better).
Actually in my expeirence senior deva are the less good with people (expierenced developers with good people skills often become twch leads.
But thats really not the point I was trying to make. The point is that no senior dev is hired for or because of those qualities (at least from what I've seen)
One of the best resources for improving your soft skills is the book "How to win friends and influence people". It's about 80 years old now, but still the best work in its category. I keep a copy at my desk for quick reminders.
Whatever it takes to make money for customers. That's it.
No, I'm not being snarky, so hear me out...
I've met and worked with many developers over the years and lots of them have become very good with technology and user domains, but still have struggled to "crack the digital ceiling". These are brilliant people who have achieved serious things, but are still not recognized by the big decision makers as "senior", whatever that means.
Then there are a select few who always get the big gigs, big money, and big reputations. Why? Because they make money for their customers. There are lots of non-technical skills that help them, but I think the biggest is their ability to separate the signal from the noise and zero in of the most important things to work on and to get them done. It's almost like they have "profitability radar". And this rarely requires any special technical or people skills. All they really have to learn is a good grasp of the technology, a deep understanding of the customer's domain and business, and the ability to get things done through others. And how did they develop them? By good old fashioned grunt work, whether digging into the bowels of the system or getting up off their butts and relentlessly going around finding out whatever they needed to know.
Once you've figured out the best thing(s) to work on to make money, got them onto the decision makers' radar, and found a way to get them done one way or the other, you are no longer a dev or even a senior dev. You're now a digital rainmaker, the most senior dev of all.
You are onto something but I think it's not directly about making money. In my view you need to be able to talk the language of executives which is quite different from how engineers communicate typically. If the CEO sees you as somebody he can talk to you have cracked the digital ceiling unless you make other mistakes.
There's a lot of great specific examples in this thread but I think it all boils down to this one quality; being able to put your own ego aside.
I think what lets a developer graduate from one level to the next is realizing that your own knowledge, vision, etc. is limited and not always the right way to go. Being able to put your own desires aside and execute someone else's vision while still providing the benefit of your experience and knowledge when appropriate.
Despite being a senior dev for a while now it's something I sometimes still struggle with finding the balance on.
I agree with this to an extent, but a controlled burst of ego can sometimes signal to the rest of the business that they're deeply off-track: "I/my team are better than spending time realising this ridiculous requirement/deadline/anti-feature, and we're just not going to do it. You need to re-think this".
I don't recommend doing it too often (no-one wants a reputation for being precious or difficult), but used correctly it can be powerful.
I don't think this works in Silicon Valley. I'm a recent transplant but I've found that people here are very passive aggressive and it's always a mistake to be direct with people. Now, in NYC I never had a problem after talking to someone about a disagreement (obviously in private). But, it's just not affective in SF.
I would say a solid understanding of the fields that development most commonly intersects with. Typically business (including politics), product, networking, operations, and security. You don't need to be an expert but you do need to be able to carry on intelligent conversations at the intersection points.
You don't need to be an expert but you do need to have a firm grasp of the basics.
Being the last man standing. Seems sad but when people leave bad company, usually the people who stay get promoted and some of them become senior developer. I have seen this strange pattern a few times.
Absolutely. A good way to make this happen is to crank out piles of write-only code. You'll look more productive than your peers and you'll be the expert on a relatively large part of the system.
When things inevitability go wrong, you'll also be the hero that powers through the weekend hacking a solution together. Be sure not to document or comment this code. It makes your memories critical to the operation of the business.
Eventually everyone else but people like you will move on. You'll be given a bigger say in the org by default AND you'll think exactly like all the other senior engineers. This will make you appear to be good at communication and working in teams since you can all say and do what you were already thinking.
Good to know I am not alone :) There are a few pinpoints also to detect if the company you are interviewing to is one of these. Usually, they are 'building' a new team for an existing product. As I grew up in my career I started to develop the reflex to ask why the previous folks left. You might not get an honest answer but at least it gives you more information either you should continue the hiring process or not.
I just had a phone interview that was incredibly telling about the company. The interviewer ... didn't speak english. And, I've been doing this long enough that I embrace that broken english is the international language of science. This guy didn't speak english. We had to communicate by typing into the pair coding app (remember this was a phone interview).
Anyway, a company who puts that person on the phone as one of the first points of contact has serious communication issues. It was an easy pass for me (I already work in a company with broken communication).
I also usually ask "if someone has left the company in the last year" or so. However, they might lie, but most of the time they are not prepared for such a question. Reading micro-expressions (I am trying to learn...!) and the tone of the voice might help you with that, so that you can dig in and put some pressure to get some truth out of it.
Ha ha. Generate the piles of code but keep the generation program private. Then being a hero and refactoring thousands of lines takes you five minutes at the weekend. Evil!
Why strange? Staying there when difficulties arise, future become incertain, keep working when it becomes boring or very messy or unrewarding, being able to do the work of the designer or the project manager because they are gone, all these are proofs that you are reliable and able. I would certainly choose such a guy for a senior position.
If you do it because you are loyal to the company and you are good at what you do, you MUST be promoted. If, on the other hand, you do it because you need a promotion and all you have to do is to wait, well... I don't have the numbers, I just know that people are human, and many humans seek the best opportunities with the least effort.
Yes, and more often than you seem to think, "waiting" is a good choice, because it leads to better opportunities in the long term. I don't advocate to stay in the same company forever. I suggest to do exactly the opposite of the flock, i.e. leave when people are coming in, and stay when people are leaving. (That's also a way to make money on the markets, maybe the only way.)
Strange in a the sense that the rational choice would be to promote your best asset while they are in the company. There are tough times in all companies but, in some, the best assets decide to leave when there are tough times because this is the last nail in the coffin of a toxic work environment.
That includes identifying useful ideas from elsewhere - conferences, magazines, books, hn, etc - then adapting them to make sense on current project, convincing the rest of the team of their fitness, and then leading the rest of the team to understand and learn them. Not a manager, a leader.
For the record, "make sense" is not the same as "cram every shiny v0.1 toy into the next project."
To know the landscape and limitations thereof surrounding a product being developed. These skills can be learned formally through school or informally by continual pursuit, as many hackers find themselves doing who come from backgrounds other than hardcore computer science.
* Communication
With stakeholders, the business folk that green-light and also those who manage projects. This one is two part since it takes a good measure of both knowing how to cut through the red tape and get the jobs done, and also how to effectively communicate with them in the language they understand.
* Programming and devops
You need to know common idioms, a common framework or three, and the way web applications are deployed and hosted. If you have programmed a ton of projects over the years you will have seen firsthand enough of the wrong ways of doing things to spot it a mile away and be able to know when something should be refactored, rewritten, or not, and be able to review others code for the same.
I'm deliberately leaving off "people management skills" because I think #3 covers that -- managing the technical output of people is the most important part for managing technical subordinates, which you will likely be at least partially responsible for as a senior dev, even if it is for developers in a mostly flat org.
Understand exactly how development fits into the rest of the business, it will vary for every company. The art of scalability is a good book to read to get started.
135 comments
[ 3.6 ms ] story [ 241 ms ] threadEdit: I do not have grey hair.
The other comments are all relevant and very good, but they seem to overlook one important aspect: the company's attitude. What all those comments have in common is that they assume things work according to Tom DeMarco's book Peopleware. I have learnt on my own experience that they don't. I have had the chance to work with 1)poisonous, 2)negative, 3)defensive (see the psychological meaning), and 4)offensive (... no psychology needed here) senior developers. Some nicer/more experienced than others, no doubts, sometimes also due to the lack of communication skills (English is not everyone's first language, and I do understand it). However, these ones were senior due to the number of years spent in the company OR their age. That's why I think that the companies that value someone's skills (I like to see them like technical skills, IQ and EQ) for their promotions are the minority.
I think if you're in a small company things could be different.
This is a funny comment, since he keeps repeating through the entire book phrases that sound like "you probably won't be able to get this for your team", "you likely never seen it anywhere, but...", "when doing our research, we've seen this. You might doubt it, but trust me, this exist on some places."
Yeah, I know. Of course I meant "things work according to the advises given by the book ..." or something like that. I read the book, and everybody agrees that "it's a great book, but in reality...".
I literally though it was funny. Describing an organization type by the name of the book that claims everywhere that it doesn't exist.
On the contrary, smoke as many cigarettes as you can in a day, have a whole bottle of whiskey every day, only eat fried foods, and sleep on your face. Within just a few months, you should have the look of seniority! It's all about finding shortcuts up the corporate ladder.
Senior devs in each of these types of companies have some skills in common and some that are particular.
The common ones, in my opinion:
* Ability to communicate with non technical folks
* Ability to estimate relatively accurately
* Willingness to do grunt work to raise team productivity
* Ability to work self sufficiently, own a big chunk of work, possibly leading small team
* Knowing when to raise an issue to higher ups
* Willingness and ability to mentor folks more junior
* Knowledge of the general software landscape for your domain, including what is buyable vs requires building
How to acquire?
* Seek mentors
* Always be learning
* Seek out folks outside of your department and learn what problems they face
* Attend conferences, technical meetups, or other online learning opportunities
* Help out
* Focus on solving problems and not on being right
Disclaimer: I have spent some time in larger orgs, but mostly as a contractor so my advice may not be applicable for those.
No good deed goes unpunished. When you step up to be a team player and do that grunt work, you open yourself up to getting more and more of it. Next thing you know you have to stand up for yourself or become a door mat.
* Deal with difficult users or customers
* Write documentation
* Go back and forth between different stakeholders to make sure everybody is on the same page
* Make sure other developers have the right tools and equipment
Depending on the manager he could be doing this but if he doesn't the senior Dev has to do it or the project fails
In healthy environments (and yes, they do exists) good deeds are actually rewarded, not punished.
Furthermore, grunt work can be an excellent opportunity to shine. For example, you can figure out a way to automate it so that the next person who works on it (which may be you again) has to spend only a fraction of the time on it. Things like running reports or generating documents tend to lend themselves really well to automation, and a little programming ability can take you a long way.
So yeah... think twice before turning away grunt work, even if you believe that you may be given more of it in the future if you agree to take it on now.
http://www.daedtech.com/the-gravitational-force-of-wage-labo...
I find that my estimates are generally all over the place and multiple attempts at predicting how much time it will take to complete an assignment don't converge as time passes. Even though I had seen and been given diverse tasks over the course of my work, I can not really pick a previous item of similar magnitude for reference.
In those occasions where I'm asked to provide a WAG to an executive or salesperson, I always multiply my first thought by 150-200%. Maybe even 300% if there's an external stakeholder (3rd party integration, something for a specific client, etc).
Some things that you would want to start focusing on:
1) Figuring out what projects come next, and designing them.
2) Figuring out what your team wants to work on, so you can shape future projects to be exciting to them. (We always have an infinite number of things to do, so you might as well pick the things that are most interesting!)
3) Doing detailed designs, so that work can be parcelled out to people that are gaining experience.
As you might guess, at this point you are doing more than working alone or working on engineering tasks that someone else defined. You are defining the tasks, and are starting to define the bigger projects.
Your individual contributions should be setting the standards for others that work with you. Write that extra test, clean up that documentation, don't launch a new service without monitoring. What you value will become what your team values, by your example.
How to get to this point? Hopefully the more senior members of your team are setting you up for success; allowing you to do some of these tasks until you're good enough to do them without supervision.
Knowledge of accounting principles is often helpful for in-house developers.
That could be removing roadblocks by flushing out designs and specs like other people have mentioned, or finding better processes and practices to make the team more effective. Of course, there is also the proper introduction of new technology or techniques to raise the company forward as well.
The ability to walk in somebody else's shoes for a while makes you a better developer. Why?
* You acquire the habit of imagining what it's like to use the stuff you develop.
* You have a feel for the daily experience of your colleagues, suppliers, executives and other stakeholders.
These things give you the sort of spidey-sense that lets you function independently. They also give you the ability to enlist other people to get things done.
How can you learn empathy? Like any skill, it takes practice.
--Listen to strangers. The question "what are you doing this afternoon" asked at lunch will usually get an interesting response. Interject "wow" - like sounds to keep them talking.
--Seek opportunities to meet end-users of your stuff. (Ask sales people to take you along on calls if that's appropriate). Observe their work.
--Ask your executives and project managers questions like, "what keeps you awake at night?" And listen to the answers.
--Teach. It doesn't matter whether you teach short courses or get a night job as an adjunct professor at your local CoCo. Your interactions with students will help develop your empathy.
People love to talk about themselves. You can take advantage of that to practice empathy.
Most of what I do can be classified as "work".
Well, the only time you'll get that out of me is when I'm angry.
Most of my weekends involve:
* Reading research papers
* Reviewing other peoples' source code
* Reporting security vulnerabilities to open source projects (usually with a patch)
* Improving these projects: https://github.com/paragonie
I never have any time to watch movies, play video games, or engage in creative hobbies.
You've probably had some bad experiences, but you'd be surprised to know many people are not out there to get you for being different.
Hmmm. Sounds to me like your profession, your hobby, and your passion are all aligned. I hope you know how rare and wonderful that is!
I don't know exactly why the other commenter said "you must be fun at parties," but I'd imagine it's because the parent commenter deflected from talking about things he actually wanted to talk about. Being fun doesn't have much to do with the content of what you talk about. It has more to do with you showing genuine interest and excitement for the things you do. If you don't like watching movies or playing video games, then it's very difficult to have a fun conversation about those things. CiPHPerCoder listed four things he enjoys doing over his weekends. Those topics are definitely not mainstream, but they do overlap with my interests. I would love to have a conversation about those things with him because it also adds to the variety of conversations I get to have.
Sorry, would have responded sooner but HN's rate-limits kicked in.
> If you don't like watching movies or playing video games, then it's very difficult to have a fun conversation about those things.
I do enjoy those activities, but I accepted a lot of responsibility (especially with making secure PHP code-- a feat some infosec folks claim is inherently impossible) and intend to finish what I started. That means missing out on a lot of great movies (Warcraft, Zootopia) and video games (OverWatch) that my friends are all able to enjoy.
Ultimately, I believe the work I'm doing today will make a difference tomorrow. Whether I'll be able to capture any of that value for myself remains to be seen.
But now I try to be as open as is practically reasonable about my interests and hobbies. You'd be surprised how receptive some people can be. And those who react negatively are filtering themselves out of further interaction.
Not all people are looking for their own words echoed back to them. Like the OP who suggested this advice in the beginning, some people are really interested in seeing things from different viewpoints.
(In spite of the stereotype, I'm always surprised to see how few genuine "introverted coders" there actually are in the industry and how unsympathetic the rest are.)
It's OK if you don't want to spend the time to explain the nuance of your personal existence, but do understand that there is nuance in everyones existence. Expecting that the other person you are talking to "won't get it" is just blatant egotism.
Taking time to express what's important to you, and why, can be a very constructive thing for those who want to listen. The OP advocates empathy, and this is where it comes from. In my personal pursuit of empathy, I've had to filter out responses from people like you, and try to see beyond the untruthful statements in an attempt to understand what they are really saying. Shyness is one thing, but a pattern of lies and deceit are indicative of fundamental imbalance.
If you're having a hard time expressing why it's important to you, consider introspection; is it really important to you? If you don't come away from a day, or week, or weekend with something to tout when prompted, I dare say "you're doing it wrong".
I'm certainly not saying that I have something to be proud of every day, but that I'm honest with myself when I don't, and will express to others that I likely accomplished less than them in a given period. No lies necessary, and the other humans around you are given an opportunity to see your similarities, instead of some false iron gate of awesomeness.
Or if I am bustling with joy because the wife and I managed to sneak in an evening of kinky sex between bringing the kids to bed and work on monday. THAT's what I am thinking about and THAT's not what I want to tell you. So I invent some stupid story just so you are satisfied.
It's OK if colleagues which I know well and with whom I have a kind of bond ask things like that. But not as a conversation starter or to create such a bond.
And the list of people who cannot stand questions like that goes on: those with depression for whom every weekend is just a period of grayness, those with social anxiety...
Inventing a story, rather than truthfully explaining that you "enjoyed spending time with your wife and daughters" sounds sick to me.
You have a bond with everyone else already: we are humans. There is no prerequisite.
As someone who identifies with both depression/anxiety and positivity toward my accomplishments, in addition to a definite introversion, I reiterate my last paragraph from above: stop lying to yourself and others. If you had a simple weekend, where is the shame in admitting it?
If it was bad enough that you can't admit it, use that to fuel your development instead of pacifying it.
Isn't that the problem? Weekends are for resting, or doing whatever you want to do, which doesn't have to be work.
But if someone complains they have too much work over the weekend.... well they should do less work then. Use the time for what it is designed for!
I see people doing all of that every weekend in my suburb. Definitely not something you should shy away from sharing.
If all you do is work work then I think you should probbably re-adjust a bit on the weekends or you'll narrow focus too or you're just working too hard. If you're doing side projects, I'm an engineer too, I LOVE to hear about that stuff. It's why I read hackaday and hacker news.
But if it's you trying to train it, the onus is on you to make it not awkward. Because everybody do default to this conversation.
Another tactic is to say "not much, what about you?" People love talking about themselves.
What do I mean? The person answering probably wonders whether his weekend adventures will compare favorably with yours. "I went to Tahoe!" "I caught a pop fly ball in Candlestick Park!" "I stayed home and binge-watched Gilligans Island." "Loser!"
Asking about the future is less competitive. Answers can range from "I'm going over to Sand Hill Road to get my investors to sign off on my IPO papers" to "StoopidCo sends this corrupt XML feed...I have to figure out how to ingest it" to "I'm going home sick, I feel terrible." In each case the answer is about the person speaking, not about you the questioner.
Do you see the difference? It's really important.
You really see the effects in the tech industry, as many of us were drawn to this line of work when we were undersocialized introverts in our teens and 20's. I know I was. I really resented social pressure in all forms, and was always pissed off that everyone else didn't see me for the genius that I thought I was at that age (which I was not, of course, but that belief was the only thing that got me out of bed some mornings). I loved the idea of a job where all that mattered were my technical skills, and never had to interact with other people, not realizing that any engineering job worth having would not fall into this category, if such jobs even existed.
I frequently see people get angry in forums when they think people are arguing with them based on the tone or wording of what they said rather than the content of their post. I frequently see people make comments in forums along the lines of, "99.9% of humanity is just too freaking sensitive and I refuse to change myself to adapt to them." More topically, you will occasionally see politicians or other public figures brush off outrage against some mind-numbingly hateful or stupid remark with excuses like, "I don't have time for political correctness", as if their lack of PC-approved verbiage was the reason people got angry. All of these things are indicators of people who not only don't have empathy but don't even realize what it is. They think empathy is like sympathy, or some other warm and fuzzy lets-share-our-feelings thing that they don't think they need to understand.
But really empathy is just the ability to have at least a shred of intuition for how things look from other people's perspectives. I think of it more as a neurological function than anything else, another high level input that our brains synthesize for us from lots of low level activity that we're not aware of, not unlike sight or hearing. It's a prerequisite for effectively communicating things to other people, and it becomes even more important when the people you are communicating with are predisposed to disagree with whatever you're saying. It's not schmoozing, it's not knowing how to sugar-coat what you say so as to not offend people (although that's often a pleasant side-effect in touchy situations!), it has nothing to do with political correctness, it's not even a social skill- it's literally just having the tiniest sense of how you come across to other people so you can communicate as effectively as possible. It also makes it much, much easier to design software that actually solves problems for other people, and to arrive at the best possible compromises in personal and business dealings. It also will aid in your awareness of problems that might not matter to you, but matter a lot to the people whose problems you want to solve.
https://www.amazon.com/Soft-Skills-software-developers-manua...
In my opinion a senior developer is someone who writes software that can be maintained without their presence. That means less clever, impressive code and more boring code that's simple and straightforward to understand that just does what it's supposed to do. It means reproducible deployments. It means tests which are up-to-date and working. It means everything is documented in a way that a junior developer, or even someone non-technical, can get value from.
In short, it means being organised.
Perhaps a better question is what non-technical skills do I need to work well in a team (as a senior or junior dev), every developer needs to know how to listen to people with different expierence and teach others about his own, whether he's junior or senior.
But thats really not the point I was trying to make. The point is that no senior dev is hired for or because of those qualities (at least from what I've seen)
No, I'm not being snarky, so hear me out...
I've met and worked with many developers over the years and lots of them have become very good with technology and user domains, but still have struggled to "crack the digital ceiling". These are brilliant people who have achieved serious things, but are still not recognized by the big decision makers as "senior", whatever that means.
Then there are a select few who always get the big gigs, big money, and big reputations. Why? Because they make money for their customers. There are lots of non-technical skills that help them, but I think the biggest is their ability to separate the signal from the noise and zero in of the most important things to work on and to get them done. It's almost like they have "profitability radar". And this rarely requires any special technical or people skills. All they really have to learn is a good grasp of the technology, a deep understanding of the customer's domain and business, and the ability to get things done through others. And how did they develop them? By good old fashioned grunt work, whether digging into the bowels of the system or getting up off their butts and relentlessly going around finding out whatever they needed to know.
Once you've figured out the best thing(s) to work on to make money, got them onto the decision makers' radar, and found a way to get them done one way or the other, you are no longer a dev or even a senior dev. You're now a digital rainmaker, the most senior dev of all.
https://blog.codeship.com/elaine-uy-tapjoy-interview/
Grow old.
I think what lets a developer graduate from one level to the next is realizing that your own knowledge, vision, etc. is limited and not always the right way to go. Being able to put your own desires aside and execute someone else's vision while still providing the benefit of your experience and knowledge when appropriate.
Despite being a senior dev for a while now it's something I sometimes still struggle with finding the balance on.
I don't recommend doing it too often (no-one wants a reputation for being precious or difficult), but used correctly it can be powerful.
1. Do good work. 2. Don't be an asshole.
You don't need to be an expert but you do need to have a firm grasp of the basics.
When things inevitability go wrong, you'll also be the hero that powers through the weekend hacking a solution together. Be sure not to document or comment this code. It makes your memories critical to the operation of the business.
Eventually everyone else but people like you will move on. You'll be given a bigger say in the org by default AND you'll think exactly like all the other senior engineers. This will make you appear to be good at communication and working in teams since you can all say and do what you were already thinking.
Anyway, a company who puts that person on the phone as one of the first points of contact has serious communication issues. It was an easy pass for me (I already work in a company with broken communication).
I also usually ask "if someone has left the company in the last year" or so. However, they might lie, but most of the time they are not prepared for such a question. Reading micro-expressions (I am trying to learn...!) and the tone of the voice might help you with that, so that you can dig in and put some pressure to get some truth out of it.
That includes identifying useful ideas from elsewhere - conferences, magazines, books, hn, etc - then adapting them to make sense on current project, convincing the rest of the team of their fitness, and then leading the rest of the team to understand and learn them. Not a manager, a leader.
For the record, "make sense" is not the same as "cram every shiny v0.1 toy into the next project."
To know the landscape and limitations thereof surrounding a product being developed. These skills can be learned formally through school or informally by continual pursuit, as many hackers find themselves doing who come from backgrounds other than hardcore computer science.
* Communication
With stakeholders, the business folk that green-light and also those who manage projects. This one is two part since it takes a good measure of both knowing how to cut through the red tape and get the jobs done, and also how to effectively communicate with them in the language they understand.
* Programming and devops
You need to know common idioms, a common framework or three, and the way web applications are deployed and hosted. If you have programmed a ton of projects over the years you will have seen firsthand enough of the wrong ways of doing things to spot it a mile away and be able to know when something should be refactored, rewritten, or not, and be able to review others code for the same.
I'm deliberately leaving off "people management skills" because I think #3 covers that -- managing the technical output of people is the most important part for managing technical subordinates, which you will likely be at least partially responsible for as a senior dev, even if it is for developers in a mostly flat org.