Specifically on the developer side of things, it's good to ask questions, but if I can answer it with lmgtfy.com then I'm going to get annoyed pretty fast, especially if you're asking me questions every 5 minutes when you can spend a little bit of time doing some research yourself. It's very valuable to me to not have to spoon feed you answers all the time.
That is not to say that there are problems that seniors shouldn't spend time mentoring junior folks on. In my experience though, some people never learned to do research on the internet in college, and almost want you to tell them how to write the code, line by line.
But from time to time, I call them out when they didn't try to do any basic research. Like googling the problem or looking up docs.
Some seem to lack good re/search skills. They don't know search operators (site, filetype, etc) or the importance of keywords (eg searching: "how to add something to thingomatic" vs "thingomatic add something"). It amazes me at the lack of proper researching skills a junior may have.
I know that when I started I couldn't even begin to search because I didn't know what I was trying to search for. Eventually you learn the keywords through some trial and error and experience.
The other thing is knowing which sites are better quality.
I don't have that many years under my belt but it's hit me a few times that if you can search things better than someone they seem to think you are smarter. Maybe more for the non-tech people.
You suggest that it's important for junior tech professionals to try and answer their own questions with, e.g., Google. But I feel like every other month I see somebody talking about all the bad habits developed by people who trust W3Schools as a credible resource because they're highly ranked on Google.
The junior professionals who most frequently need to find quick answers for straightforward questions are the same people who are the least well-equipped to identify which answers are credible and appropriate. It's a paradox of finding trustworthy information without consulting the only sources you know to be trustworthy, and as someone new to the field myself, I lose sleep over this stuff.
Isn't that what the code review process would be for? Let a junior developer create a solution on their own, review their work and provide constructive feedback in a way that would eventually teach them that resources like W3Schools are not to be wholly trusted?
On the flip side of the coin, there are also terrible mentors and senior developers who will gladly pass on bad habits just like W3Schools will. Independant research is a good thing.
Something else: if you ask me questions, I answer them, and you keep asking the same questions, it becomes clear that you aren't actually listening or wanting to get a deep understanding of the topic. Continually asking shallow questions and not showing a desire to get better will irritate me quickly.
Probe me to get an understanding that would be difficult to find just by doing a quick documentation lookup and I'll be happy to help. But if your questions continually come from answers that were covered in the "Quick Start," god help you.
Sometimes there is advice that seems wrong, but is actually really good advice. This isn't one of those times.
The best advice for a young Jr anything is to do the job you were hired for exceedingly well. If the words obnoxious or needy are ever used in the same sentence as your name, you are doing something terribly wrong.
The article actually supported its position with some degree of argumentation, while you just made a unfounded statement. Could you provide more details as to why you think the advice of this article is bad?
Do you really need explanation as to why you shouldn't be needy and obnoxious? I find it hard to believe that you need some empirical evidence to prove this point.
Person X has never been regarded as needy or obnoxious and is generally really great to be around. He is a junior engineer and spends a lot of time making sure everyone around him is as happy as possible by making sure he always completes anything assigned to him quickly.
Person Y is generally regarded well, but people expect him to always ask them questions so they tend to avoid him. He's often referred to as needy and sometimes even as obnoxious. If you're doing something he doesn't know about, expect him to be hovering around trying to work out what you're doing and why.
What happens if person X and Y stay at a big corporation? Person X is probably going to be promoted up a few rungs. If he is lucky he will eventually end up high in the organization. If he is unlucky or too nice, he will end up stuck in a dead end job doing the work of 5 people for the pay of 1 person. Person Y is probably going nowhere.
What happens if X or Y decide to create a new startup? Person X only knows about engineering - and only small stuff, not the big picture. It's unlikely his startup would succeed. Person Y, however, has spend the last few years trying to understand everything about business/engineering/sales etc that he can get his hands on. His startup has far better odds.
This is what the article is arguing. I find it hard to believe you DON'T need some evidence to assume person Y is always wrong. I've been person X before - I would not recommend it. Always make sure you understand the reasons behind anything you are doing, never just 'follow orders' or do anything you don't understand. Life is too short.
So, there's a really interesting thing here, right?
On the engineering side of things, it's often that things are hard but tractable--there is a clear set of goals that need to be accomplished, and at least a somewhat reasonable dependency graph of objectives that can be inferred to reach those goals.
Over in sales and business, though? OH GOD everything's on fire--we have too many customers and not enough product, too few customers and too much engineering, a great opportunity for a strategic partnership, wait no that isn't panning out, nobody likes us fuck fuck fuck what do we do.
(And from what I've observed of sales and business folks, this sort of bipolar behavior is totally expected. They are in a deep, ongoing, and tumultuous relationship with your product and your customers, and things get crazy sometimes.)
As a junior engineer it can be really disheartening to learn that your company has few customers and the ones you do have hate your product for reason X (where X probably is nothing you have direct control over). Especially in a small company, business is a howling vortex of crazy that honestly as a junior engineer you probably don't have the experience to make sense of.
One of the most poignant lessons from Soul of a New Machine was that the Eagle team pulled off so much awesome work precisely because they were insulated from the rest of the company and allowed to focus on the engineering.
I think a really good depiction of this struggle is Mad Men, surprisingly enough. You've got two factions of symbiotic employees who have more or less differing objectives. (Thankfully, I haven't had to work with any Pete Campbells.)
A lot of this has to do with the way we incentivize/disincentivize various business roles. At your average company, an engineer/developer's #1 goal is "don't fuck up", meaning: take time and caution when developing and releasing things and don't do anything that could break anything (both in the sense of 'throw an error' and 'cause a customer to leave'. The latter is especially important in the enterprise space, where a single customer can be worth more than 10% of your revenues and act as a marketing engine through whitepapers and referrals.)
On the other side of things, sales folks are usually incentivized to sell, sell, sell. They get paid to sell things, so any behavior that doesn't maximize their ability to increase their commission is actively disadvantageous to them. Usually, this incurs a sort of long-term blindness: by devoting three developers to feature ABC for a week and making $X, you take them away from perhaps a bigger feature that might make the company $X * 10. Plus, by making time-sensitive promises to clients/customers you limit the engineer's ability to not fuck up.
The answer to this isn't "sales people are bad and should be more honest" or "engineers should be better at what they do". There are a lot of different strategies: at smaller companies, you'll see ideals like uniting sales and marketing ("marketing" not in the sense of advertising, but in the sense of product development) but the biggest successes I've seen have revolved around shifting those incentives: commissions are simple and easy to tinker with (there's a lot of new interesting literature about 'recurring commissions' which reward salespeople for longer-lasting customers), but your average engineer at a firm deserves a better incentive to produce quality work than "if you don't you will look bad." Sales commissions for engineers may sound weird, but I think if you remove the decades of context there's nothing crazy about the idea that if someone creates a feature that generates $6million for their company, they're entitled to a small slice of that $6million.
One thing I'll caution about, though. One of the more depressing moments I had at a prior gig was realizing that the project I'd been working on (a pretty big overhaul of the 3D interface for a tool) was probably not actually getting us any customers, was probably too complicated for the customers to use (our market was AEC, and the next generation of architects cannot take over fast enough!), and in general that I was getting paid to (seemingly) add no value to the company.
Because I didn't (presumably) see the bigger picture, I got into a pretty sad place as I tried to complete work on something that didn't seem to matter from my limited knowledge of things outside engineering. In short, a little extra knowledge is a dangerous thing; had I known less, I could've happily chugged away, and had I known more, I might've been able to see the point in what I was doing.
So, pegging rewards for engineering efforts to direct profitability could maybe have some bad side-effects.
Being this guy is great fun, but honestly try avoid being obnoxious and /too/ needy. It's a great way to learn but its also a great way to find yourself out of a job, you need to get your work done and other people don't need the distractions.
Learn as much as you can, but maintain a high level of respect for peoples time, including your own.
Good article, I particularly noticed the "just to listen" in meetings bit. If you want to provide a lot of value in this role?
Take good notes. What meeting, when, where, with who? Who is in person/remote? Write as fast as you can, capture "todos", "next steps", follow up items of all kinds, important decisions. After the meeting, email the participants with your notes. Put them in your document repository (wiki, sharepoint, SCM if you must).
This way you provide value, people see you, and they see that you are paying attention. It also gives you good fodder to ask questions later, e.g. "What did XYZ term mean?", "Why was Laura asking about question Y?", "Did no one think of X, or was it obvious?"
Taking good notes is an art, and it's easiest when you are "just" listening.
Personally if you are a jr programmer on one of my teams I would be unimpressed if you felt the need to aggressively pursue external meetings so you could just sit and listen, or spend work time meeting with the CFO to discuss how much we pay the auditors.
Get to work, it's what you're being paid for. Don't forget that.
Any employee who pulls his weight and also expands his knowledge is massively more useful than one with the wage slave mentality you appear to be condoning.
I dislike the attitude that he's showing, but I'm glad that he's showing it because the way thinks is not atypical in corporate middle management.
I would hazard the guess that, in 90 percent of companies, a person doing above-grade work that is more interesting than his assigned job-- even if that person is fully "pulling his weight"-- develops a negative reputation that will eventually harm his career. Sadly, perception matters more than what is actually happening.
Also, keep in mind that the real job of management and executives in most companies is reputation management. Their actual purpose is to sustain the reputation of the company so it can trade its wares (produced by the workers) at an advantageous rate. The test of the white-collar peon is how well he supports his manager's reputation. That's why middle managers are allowed to demand total loyalty of their reports. Above-board work that the manager didn't direct ends up minimizing the boss, so any benefit to the company doesn't really matter. I hate that it's that way; companies would be a lot better if people were trusted to work directly for the firm, Valve style, but that's not how most firms operate.
I see a lot of people with the "get your head down and code" attitude, and it MAY be appropriate at the junior level.
At the senior level - as you note - someone has to make sure that the RIGHT work is being done, not simply that a LARGE AMOUNT of work is being done. That requires you to get your head up and communicate with other departments.
With respect to your comment; I ran cross-country in high school. We trained in certain zones called VDOT's, and in the VDOTS were times on how fast you should be running for 800m, 1600m etc. The only way we got better was pushing ourselves outside of our VDOT suggested times, and entering the higher VDOT times. If we simply "got to work" we would never get better, only becoming good at what we were told is our limit (represented by the times in our VDOT).
"Getting to work" means "working on what you're working on while improving upon what you're working on". I don't see how that differs from pushing yourself outside of your VDOT times.
What's being advocated in the article is going to watch the high jump practice. While you might gain some insight into, say, different training techniques, you won't learn very much that is going to help you maintain your times, let alone improve upon them.
I think that looking at different parts of a system does in fact help you improve on whatever it is you are doing. Developing an understanding of any system in depth is imperative to getting better. Why would one want to study Calculus if all that person will be doing is programming? Thinking outside the box helps stretch the creative process to cover more than convention allows.
and "Ask for sensitive information, even if it's personal at times" FFS thats just asking for trouble.
Hint if you accessed sensitive information with out authorization in many places you will be in trouble.
At my last place my boss was a director and there where things about major changes in the company that he knew about and impacted my job but he was contractual and legally bound not to say anything till its announced.
Then you can still ask, and if he really can't or won't tell you he'll say no. Curiosity in what's going on over your head, particularly when it comes to structural decisions that will affect you, your employment status, or your day-to-day work, is healthy.
Get to work, it's what you're being paid for. Don't forget that.
You sound incredibly entitled. While I agree that it's strategically a bad idea for him to go outside of his job description, why is it not "work" for him to want to know how the company runs? He's not looking to upset apple carts; he just wants to know how the decisions are made.
Anyway, I hate this attitude you're showing. I'm not downvoting you, because people need to see that your attitude exists (as it's fairly prevalent) so it shouldn't be buried, but I find it this "fuck you, I'm the boss" attitude revolting.
I was a jr programmer once as well and I was curious and engaged people outside my direct work assignments but was always focused on making sure the work I was expected to do got done.
More than enough time is wasted in project specific meetings so actively looking to sit in on unrelated meetings screams 'wasted time'.
I'm not 'entitled' I'm speaking as someone under pressure to deliver software projects and to explain why they may be late or off course.
If I have a jr programmer who is constantly away trying to understand how to run a business so he/she can fly the coup to start their own company then I'm not going to be impressed with said programmer.
I enjoy working with people who are creative, engaged, and curious -- but also focused.
Somehow, I suspect that while you might be upset with him, and even let him go, that junior dev will be better off learning what he can and then jumping ship then staying and working diligently in subservience. This advice is not how to make your managers happy by advancing their careers, it is how to make yourself happy by advancing your career.
My comments are not about advancing anyone's career. When you are a junior member of a software development team your primary objective should be to help the team deliver the project. There's a reason you have 'jr' in your job title.
There are some interestingly ironic comments about how the team lead is labeled as 'entitled' and 'advancing my career' when the OP is essentially advocating those same concepts from a different perspective.
I get the sense from the tone of comments that there are a lot more jr programmers on this thread than sr programmers.
It's also a bit of a drag on your fellow developers. If I'm a senior dev working on my tasklist, and we hire a junior dev who goes off to go see what marketing's doing instead of working on his tasklist, it would really start to get me pissed off. It doesn't matter that he might be a superstar and knocking off his tasks in 25% of the estimated time, what matters is that the department that we're both in has things that need doing, and by buggering off to talk with the CTO he's not helping get those things done.
spend work time meeting with the CFO to discuss how much we pay the auditors
I think you may have misread that section - I don't think it was about calling the auditors out on being lazy; I read it as "they're fair game to ask questions," i.e. if they're in the break room at the same time as you, ask the auditors about their career path/what they do/how to be successful like them.
I understand where the author is coming from, but your curiosity needs to be organic and come from a real yearning to understand the business. I can see a lot of young engineers thinking they need to voraciously hunt down random higher-ups 'just because'.
There's no shortage of things to learn in an organization and sometimes it's best to start in an area closer to you (see: with Sr. Engineers).
It's perfectly possible to sponge up knowledge from Sr. Engineers, while picking up different bits of knowledge from people who are in different roles altogether.
I opened the comments here to see if anyone else had this problem. I made a Chrome extension that fixes it. Unlike tools like readability, all it does is take the thing you click on and change it into a large black-on-white font.
This is one of those things that requires a balance. I do not want a junior asking me something that they could just as easily Google.
I DO want them to ask me about some company- or domain- specific tech, so I can save them a day of research with a two-minute explanation.
If I can unstick them when they are stuck, that's great. If they get stuck every fifth line of code, or on simple problems, that's terrible.
The advice to listen more than you talk is excellent. Soak up information and then take questions offline. You don't want to be "that guy" who holds important high-level meeting with newbie questions, or derail a business discussion with questions about engineering trivia.
If I can unstick them when they are stuck, that's great. If they get stuck every fifth line of code, or on simple problems, that's terrible.
Couldn't have said it better myself. I give leeway to the new hires to learn the domain-specific stuff, but it becomes quickly obvious if they aren't picking up on the material. I had a guy not understand that "4883-381" would not be interpreted by Python as a string without the quotes after 8+ months of working with the language. At one point I caught him trying to put arguments outside of parenthesis. I realized he had basically been copying and pasting the entire time, banging his head against the wall until something worked. I almost went postal.
Bad advice. Let me just say that off the bat, before I explain why.
One of the most infuriating things about companies is how slow they are when it comes to trusting people. (Actually, they're sluggish around all kinds of decisions. Try selling to the enterprise some time.) While companies do value initiative and curiosity in the abstract, the length of time (even in most startups) one has to spend at them is an order of magnitude longer than makes any sense at all.
If you're 6 months old in a company, but your manager only gets to spend 5% of his time with you (which is more than you'll typically get) then, from his perspective, you've been there for 1.3 weeks. You just got there, in his view. This really sucks, because it means a lot of time is wasted on the pokey track by people who feel like they could be advancing a lot faster (and are right).
Typically, it takes a couple years before you're allowed to show initiative or curiosity, or have opinions. The dues-paying period is a horrible waste of life, but that's how human organizations are. I don't think anyone has found a cure for it.
Being that obnoxious junior programmer is actually a terrible career strategy. Gaining credibility is often more potent than learning; there are a zillion people more capable of doing the top jobs than hold them at a given time, but only a few people acquire the organizational trust. Credibility, not capability, is the limiting factor. Learning general-purpose skills can be more useful than climbing a ladder (it's transferrable to the next job) but you don't have to step on toes to do that; while learning about an organization is less important than having it learn to trust you. (If you fail and get fired; everything you learned about the organization is useless.)
Now, the thing is that when a company is running well and there's plenty of work to do, the overperformer who is eagerly seeking work "above his grade" is tolerated. The problem is that, whenever things become a bit more uncertain or it becomes clear that not all peoples' ambitions will be satisfied, they're high-class trophy-fires with giant bulls'-eyes on their asses. They also tend to get flanked by same-rank colleagues; if there's some Little Eichmann out there who can gain managerial approval by showing you up as "distracted", then watch out. Remember that it will have nothing to do with actual performance, but perception, which is ruined by the above-grade work.
Typically, it takes a couple years before you're allowed to show initiative or curiosity, or have opinions. The dues-paying period is a horrible waste of life, but that's how human organizations are. I don't think anyone has found a cure for it.
Comments
Specifically on the developer side of things, it's good to ask questions, but if I can answer it with lmgtfy.com then I'm going to get annoyed pretty fast, especially if you're asking me questions every 5 minutes when you can spend a little bit of time doing some research yourself. It's very valuable to me to not have to spoon feed you answers all the time.
That is not to say that there are problems that seniors shouldn't spend time mentoring junior folks on. In my experience though, some people never learned to do research on the internet in college, and almost want you to tell them how to write the code, line by line.
I tend to encourage my juniors to ask questions.
But from time to time, I call them out when they didn't try to do any basic research. Like googling the problem or looking up docs.
Some seem to lack good re/search skills. They don't know search operators (site, filetype, etc) or the importance of keywords (eg searching: "how to add something to thingomatic" vs "thingomatic add something"). It amazes me at the lack of proper researching skills a junior may have.
I know that when I started I couldn't even begin to search because I didn't know what I was trying to search for. Eventually you learn the keywords through some trial and error and experience. The other thing is knowing which sites are better quality.
I don't have that many years under my belt but it's hit me a few times that if you can search things better than someone they seem to think you are smarter. Maybe more for the non-tech people.
You suggest that it's important for junior tech professionals to try and answer their own questions with, e.g., Google. But I feel like every other month I see somebody talking about all the bad habits developed by people who trust W3Schools as a credible resource because they're highly ranked on Google.
The junior professionals who most frequently need to find quick answers for straightforward questions are the same people who are the least well-equipped to identify which answers are credible and appropriate. It's a paradox of finding trustworthy information without consulting the only sources you know to be trustworthy, and as someone new to the field myself, I lose sleep over this stuff.
Isn't that what the code review process would be for? Let a junior developer create a solution on their own, review their work and provide constructive feedback in a way that would eventually teach them that resources like W3Schools are not to be wholly trusted?
On the flip side of the coin, there are also terrible mentors and senior developers who will gladly pass on bad habits just like W3Schools will. Independant research is a good thing.
I disagree. Juniors need the skills of looking things up on Google or they'll never develop them.
Something else: if you ask me questions, I answer them, and you keep asking the same questions, it becomes clear that you aren't actually listening or wanting to get a deep understanding of the topic. Continually asking shallow questions and not showing a desire to get better will irritate me quickly.
Probe me to get an understanding that would be difficult to find just by doing a quick documentation lookup and I'll be happy to help. But if your questions continually come from answers that were covered in the "Quick Start," god help you.
Sometimes there is advice that seems wrong, but is actually really good advice. This isn't one of those times.
The best advice for a young Jr anything is to do the job you were hired for exceedingly well. If the words obnoxious or needy are ever used in the same sentence as your name, you are doing something terribly wrong.
The article actually supported its position with some degree of argumentation, while you just made a unfounded statement. Could you provide more details as to why you think the advice of this article is bad?
Do you really need explanation as to why you shouldn't be needy and obnoxious? I find it hard to believe that you need some empirical evidence to prove this point.
Let's take two people.
Person X has never been regarded as needy or obnoxious and is generally really great to be around. He is a junior engineer and spends a lot of time making sure everyone around him is as happy as possible by making sure he always completes anything assigned to him quickly.
Person Y is generally regarded well, but people expect him to always ask them questions so they tend to avoid him. He's often referred to as needy and sometimes even as obnoxious. If you're doing something he doesn't know about, expect him to be hovering around trying to work out what you're doing and why.
What happens if person X and Y stay at a big corporation? Person X is probably going to be promoted up a few rungs. If he is lucky he will eventually end up high in the organization. If he is unlucky or too nice, he will end up stuck in a dead end job doing the work of 5 people for the pay of 1 person. Person Y is probably going nowhere.
What happens if X or Y decide to create a new startup? Person X only knows about engineering - and only small stuff, not the big picture. It's unlikely his startup would succeed. Person Y, however, has spend the last few years trying to understand everything about business/engineering/sales etc that he can get his hands on. His startup has far better odds.
This is what the article is arguing. I find it hard to believe you DON'T need some evidence to assume person Y is always wrong. I've been person X before - I would not recommend it. Always make sure you understand the reasons behind anything you are doing, never just 'follow orders' or do anything you don't understand. Life is too short.
So, there's a really interesting thing here, right?
On the engineering side of things, it's often that things are hard but tractable--there is a clear set of goals that need to be accomplished, and at least a somewhat reasonable dependency graph of objectives that can be inferred to reach those goals.
Over in sales and business, though? OH GOD everything's on fire--we have too many customers and not enough product, too few customers and too much engineering, a great opportunity for a strategic partnership, wait no that isn't panning out, nobody likes us fuck fuck fuck what do we do.
(And from what I've observed of sales and business folks, this sort of bipolar behavior is totally expected. They are in a deep, ongoing, and tumultuous relationship with your product and your customers, and things get crazy sometimes.)
As a junior engineer it can be really disheartening to learn that your company has few customers and the ones you do have hate your product for reason X (where X probably is nothing you have direct control over). Especially in a small company, business is a howling vortex of crazy that honestly as a junior engineer you probably don't have the experience to make sense of.
One of the most poignant lessons from Soul of a New Machine was that the Eagle team pulled off so much awesome work precisely because they were insulated from the rest of the company and allowed to focus on the engineering.
I think a really good depiction of this struggle is Mad Men, surprisingly enough. You've got two factions of symbiotic employees who have more or less differing objectives. (Thankfully, I haven't had to work with any Pete Campbells.)
A lot of this has to do with the way we incentivize/disincentivize various business roles. At your average company, an engineer/developer's #1 goal is "don't fuck up", meaning: take time and caution when developing and releasing things and don't do anything that could break anything (both in the sense of 'throw an error' and 'cause a customer to leave'. The latter is especially important in the enterprise space, where a single customer can be worth more than 10% of your revenues and act as a marketing engine through whitepapers and referrals.)
On the other side of things, sales folks are usually incentivized to sell, sell, sell. They get paid to sell things, so any behavior that doesn't maximize their ability to increase their commission is actively disadvantageous to them. Usually, this incurs a sort of long-term blindness: by devoting three developers to feature ABC for a week and making $X, you take them away from perhaps a bigger feature that might make the company $X * 10. Plus, by making time-sensitive promises to clients/customers you limit the engineer's ability to not fuck up.
The answer to this isn't "sales people are bad and should be more honest" or "engineers should be better at what they do". There are a lot of different strategies: at smaller companies, you'll see ideals like uniting sales and marketing ("marketing" not in the sense of advertising, but in the sense of product development) but the biggest successes I've seen have revolved around shifting those incentives: commissions are simple and easy to tinker with (there's a lot of new interesting literature about 'recurring commissions' which reward salespeople for longer-lasting customers), but your average engineer at a firm deserves a better incentive to produce quality work than "if you don't you will look bad." Sales commissions for engineers may sound weird, but I think if you remove the decades of context there's nothing crazy about the idea that if someone creates a feature that generates $6million for their company, they're entitled to a small slice of that $6million.
Excellent points!
One thing I'll caution about, though. One of the more depressing moments I had at a prior gig was realizing that the project I'd been working on (a pretty big overhaul of the 3D interface for a tool) was probably not actually getting us any customers, was probably too complicated for the customers to use (our market was AEC, and the next generation of architects cannot take over fast enough!), and in general that I was getting paid to (seemingly) add no value to the company.
Because I didn't (presumably) see the bigger picture, I got into a pretty sad place as I tried to complete work on something that didn't seem to matter from my limited knowledge of things outside engineering. In short, a little extra knowledge is a dangerous thing; had I known less, I could've happily chugged away, and had I known more, I might've been able to see the point in what I was doing.
So, pegging rewards for engineering efforts to direct profitability could maybe have some bad side-effects.
Being this guy is great fun, but honestly try avoid being obnoxious and /too/ needy. It's a great way to learn but its also a great way to find yourself out of a job, you need to get your work done and other people don't need the distractions.
Learn as much as you can, but maintain a high level of respect for peoples time, including your own.
Good article, I particularly noticed the "just to listen" in meetings bit. If you want to provide a lot of value in this role?
Take good notes. What meeting, when, where, with who? Who is in person/remote? Write as fast as you can, capture "todos", "next steps", follow up items of all kinds, important decisions. After the meeting, email the participants with your notes. Put them in your document repository (wiki, sharepoint, SCM if you must).
This way you provide value, people see you, and they see that you are paying attention. It also gives you good fodder to ask questions later, e.g. "What did XYZ term mean?", "Why was Laura asking about question Y?", "Did no one think of X, or was it obvious?"
Taking good notes is an art, and it's easiest when you are "just" listening.
Personally if you are a jr programmer on one of my teams I would be unimpressed if you felt the need to aggressively pursue external meetings so you could just sit and listen, or spend work time meeting with the CFO to discuss how much we pay the auditors.
Get to work, it's what you're being paid for. Don't forget that.
Any employee who pulls his weight and also expands his knowledge is massively more useful than one with the wage slave mentality you appear to be condoning.
I dislike the attitude that he's showing, but I'm glad that he's showing it because the way thinks is not atypical in corporate middle management.
I would hazard the guess that, in 90 percent of companies, a person doing above-grade work that is more interesting than his assigned job-- even if that person is fully "pulling his weight"-- develops a negative reputation that will eventually harm his career. Sadly, perception matters more than what is actually happening.
Also, keep in mind that the real job of management and executives in most companies is reputation management. Their actual purpose is to sustain the reputation of the company so it can trade its wares (produced by the workers) at an advantageous rate. The test of the white-collar peon is how well he supports his manager's reputation. That's why middle managers are allowed to demand total loyalty of their reports. Above-board work that the manager didn't direct ends up minimizing the boss, so any benefit to the company doesn't really matter. I hate that it's that way; companies would be a lot better if people were trusted to work directly for the firm, Valve style, but that's not how most firms operate.
I see a lot of people with the "get your head down and code" attitude, and it MAY be appropriate at the junior level.
At the senior level - as you note - someone has to make sure that the RIGHT work is being done, not simply that a LARGE AMOUNT of work is being done. That requires you to get your head up and communicate with other departments.
With respect to your comment; I ran cross-country in high school. We trained in certain zones called VDOT's, and in the VDOTS were times on how fast you should be running for 800m, 1600m etc. The only way we got better was pushing ourselves outside of our VDOT suggested times, and entering the higher VDOT times. If we simply "got to work" we would never get better, only becoming good at what we were told is our limit (represented by the times in our VDOT).
"Getting to work" means "working on what you're working on while improving upon what you're working on". I don't see how that differs from pushing yourself outside of your VDOT times.
What's being advocated in the article is going to watch the high jump practice. While you might gain some insight into, say, different training techniques, you won't learn very much that is going to help you maintain your times, let alone improve upon them.
I think that looking at different parts of a system does in fact help you improve on whatever it is you are doing. Developing an understanding of any system in depth is imperative to getting better. Why would one want to study Calculus if all that person will be doing is programming? Thinking outside the box helps stretch the creative process to cover more than convention allows.
and "Ask for sensitive information, even if it's personal at times" FFS thats just asking for trouble.
Hint if you accessed sensitive information with out authorization in many places you will be in trouble.
At my last place my boss was a director and there where things about major changes in the company that he knew about and impacted my job but he was contractual and legally bound not to say anything till its announced.
Then you can still ask, and if he really can't or won't tell you he'll say no. Curiosity in what's going on over your head, particularly when it comes to structural decisions that will affect you, your employment status, or your day-to-day work, is healthy.
Get to work, it's what you're being paid for. Don't forget that.
You sound incredibly entitled. While I agree that it's strategically a bad idea for him to go outside of his job description, why is it not "work" for him to want to know how the company runs? He's not looking to upset apple carts; he just wants to know how the decisions are made.
Anyway, I hate this attitude you're showing. I'm not downvoting you, because people need to see that your attitude exists (as it's fairly prevalent) so it shouldn't be buried, but I find it this "fuck you, I'm the boss" attitude revolting.
I was a jr programmer once as well and I was curious and engaged people outside my direct work assignments but was always focused on making sure the work I was expected to do got done.
More than enough time is wasted in project specific meetings so actively looking to sit in on unrelated meetings screams 'wasted time'.
I'm not 'entitled' I'm speaking as someone under pressure to deliver software projects and to explain why they may be late or off course.
If I have a jr programmer who is constantly away trying to understand how to run a business so he/she can fly the coup to start their own company then I'm not going to be impressed with said programmer.
I enjoy working with people who are creative, engaged, and curious -- but also focused.
Call it what you will.
Somehow, I suspect that while you might be upset with him, and even let him go, that junior dev will be better off learning what he can and then jumping ship then staying and working diligently in subservience. This advice is not how to make your managers happy by advancing their careers, it is how to make yourself happy by advancing your career.
Perhaps I should have said: focus on your work.
My comments are not about advancing anyone's career. When you are a junior member of a software development team your primary objective should be to help the team deliver the project. There's a reason you have 'jr' in your job title.
There are some interestingly ironic comments about how the team lead is labeled as 'entitled' and 'advancing my career' when the OP is essentially advocating those same concepts from a different perspective.
I get the sense from the tone of comments that there are a lot more jr programmers on this thread than sr programmers.
I suspect some of the adverse reactions are because of the focus on the 'jr'.
Shouldn't all members of a software development team have a primary (work) objective of delivering the project?
It's also a bit of a drag on your fellow developers. If I'm a senior dev working on my tasklist, and we hire a junior dev who goes off to go see what marketing's doing instead of working on his tasklist, it would really start to get me pissed off. It doesn't matter that he might be a superstar and knocking off his tasks in 25% of the estimated time, what matters is that the department that we're both in has things that need doing, and by buggering off to talk with the CTO he's not helping get those things done.
Objecting to his attitude is above your pay grade, son.
I think you may have misread that section - I don't think it was about calling the auditors out on being lazy; I read it as "they're fair game to ask questions," i.e. if they're in the break room at the same time as you, ask the auditors about their career path/what they do/how to be successful like them.
I understand where the author is coming from, but your curiosity needs to be organic and come from a real yearning to understand the business. I can see a lot of young engineers thinking they need to voraciously hunt down random higher-ups 'just because'.
There's no shortage of things to learn in an organization and sometimes it's best to start in an area closer to you (see: with Sr. Engineers).
False dichotomy.
It's perfectly possible to sponge up knowledge from Sr. Engineers, while picking up different bits of knowledge from people who are in different roles altogether.
How about some contrast on this page? I used the chrome inspector to change the font color to black.
I opened the comments here to see if anyone else had this problem. I made a Chrome extension that fixes it. Unlike tools like readability, all it does is take the thing you click on and change it into a large black-on-white font.
https://chrome.google.com/webstore/detail/text-fix/ofafkoecd...
This is one of those things that requires a balance. I do not want a junior asking me something that they could just as easily Google.
I DO want them to ask me about some company- or domain- specific tech, so I can save them a day of research with a two-minute explanation.
If I can unstick them when they are stuck, that's great. If they get stuck every fifth line of code, or on simple problems, that's terrible.
The advice to listen more than you talk is excellent. Soak up information and then take questions offline. You don't want to be "that guy" who holds important high-level meeting with newbie questions, or derail a business discussion with questions about engineering trivia.
Couldn't have said it better myself. I give leeway to the new hires to learn the domain-specific stuff, but it becomes quickly obvious if they aren't picking up on the material. I had a guy not understand that "4883-381" would not be interpreted by Python as a string without the quotes after 8+ months of working with the language. At one point I caught him trying to put arguments outside of parenthesis. I realized he had basically been copying and pasting the entire time, banging his head against the wall until something worked. I almost went postal.
Just be sociable and network. Works at all levels, and in personal as well as professional pursuits.
You don't need to be obnoxious or needy.
Friendly tip: you may want to make the font a little darker on your blog! It's hard to read with that little contrast.
You might want to consider a media query for that sidebar.
Bad advice. Let me just say that off the bat, before I explain why.
One of the most infuriating things about companies is how slow they are when it comes to trusting people. (Actually, they're sluggish around all kinds of decisions. Try selling to the enterprise some time.) While companies do value initiative and curiosity in the abstract, the length of time (even in most startups) one has to spend at them is an order of magnitude longer than makes any sense at all.
If you're 6 months old in a company, but your manager only gets to spend 5% of his time with you (which is more than you'll typically get) then, from his perspective, you've been there for 1.3 weeks. You just got there, in his view. This really sucks, because it means a lot of time is wasted on the pokey track by people who feel like they could be advancing a lot faster (and are right).
Typically, it takes a couple years before you're allowed to show initiative or curiosity, or have opinions. The dues-paying period is a horrible waste of life, but that's how human organizations are. I don't think anyone has found a cure for it.
Being that obnoxious junior programmer is actually a terrible career strategy. Gaining credibility is often more potent than learning; there are a zillion people more capable of doing the top jobs than hold them at a given time, but only a few people acquire the organizational trust. Credibility, not capability, is the limiting factor. Learning general-purpose skills can be more useful than climbing a ladder (it's transferrable to the next job) but you don't have to step on toes to do that; while learning about an organization is less important than having it learn to trust you. (If you fail and get fired; everything you learned about the organization is useless.)
Now, the thing is that when a company is running well and there's plenty of work to do, the overperformer who is eagerly seeking work "above his grade" is tolerated. The problem is that, whenever things become a bit more uncertain or it becomes clear that not all peoples' ambitions will be satisfied, they're high-class trophy-fires with giant bulls'-eyes on their asses. They also tend to get flanked by same-rank colleagues; if there's some Little Eichmann out there who can gain managerial approval by showing you up as "distracted", then watch out. Remember that it will have nothing to do with actual performance, but perception, which is ruined by the above-grade work.
Well I know where it probably comes from.
You're Fired!!! LOL j/k