Be The Obnoxious Needy Junior Programmer
scottkle.in
scottkle.in
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 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.
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.
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.
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.
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.
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.
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.
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.
Learn as much as you can, but maintain a high level of respect for peoples time, including your own.
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.
Get to work, it's what you're being paid for. Don't forget that.
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.
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.
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.
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.
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.
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.
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.
Shouldn't all members of a software development team have a primary (work) objective of delivering the project?
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.
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.
https://chrome.google.com/webstore/detail/text-fix/ofafkoecd...
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.
You don't need to be obnoxious or needy.
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.