I feel it's completely acceptable to wish to stay in an IC position, but to refuse outright to give advise or share the experience (it's hard to tell from your short paragraph) seems... odd?
It's acceptable to want to stay in a specific role, but I am not certain I feel it's acceptable to eschew an increasing responsibility or mentoring role as you gain experience. That way lies the "genius programmer that works alone and writes code no one else wunderstands".
It’s the same as not solving chat request bypassing prioritization.
The company is full of incentives to ask that guy for guidance/things, if he doesn’t say no most or all of the time, he simply won’t have time for his IC role, and would remain a lead just not in name.
It’s hard that it comes to that extreme measure, but if his requests aren’t being heard, it’s either that or leaving. The company has to let him be an IC or explicitly tell him that he can’t stay there as IC, are at least negotiate some timme allocation for those requests and log them
Another simple trick if you don't like saying "no": become a freelancer.
It will never ever occur to anybody in the company that a freelance software dev could possibly be put into a management role, so they won't ask. As opposed to an employed software dev.
Bonus if you're in the EU/UK: in most countries in the EU this will even lead to tax breaks and higher before-tax hourly rates. To the point that you'll make (way) more than your "higher"-up(s).
> It will never ever occur to anybody in the company that a freelance software dev could possibly be put into a management role...
If by "freelancer" you mean "contractor", then this statement is false. I had worked at multiple places in the UK where this happened, I suppose mostly because paying these people a salary would have required an disproportionate amount of money (as opposed to a standard daily rate) - UK taxes are very high in the top bracket.
If by "freelancer" you mean a real freelancer (the guy who has multiple short gigs at the same time, and needs to be constantly on the lookout for new opportunities) then that is already half of a management position, even if you don't have anyone reporting for you.
It is true though that as a contractor one can reasonably easily avoid management duties, and enjoy not having to worry about company politics. The downside is that it is easy to end up in a place where you have to accept that comparably junior people dictate architecture and some tech decisions which you discarded 10 years ago as ineffective, stupid, fad, or all of the above (TDD being a typical example). The upside is that your time at each place is limited anyway, and there is always something to learn...
Shots fired! I love tests, but I mostly agree with you. The whole idea of 'write your tests first' is great if everything is precisely defined. I find it odd I haven't seen more pragmatism around unit testing in the blogosphere. It's TDD or death out there.
Where not everything is precisely defined but "you know the right outcome when you see it" is where I think snapshot test driven development really shines:
E.g. "define API call -> don't define API response -> write the code that spits out the correct response -> auto-rewrite the test according to the response and commit".
> Bonus if you're in the EU/UK: in most countries in the EU this will even lead to tax breaks and higher before-tax hourly rates.
Having been a contractor in the UK for 5 years, I don't think this is true. Between VAT, Company and Dividend tax, the taxman (HMRC) always gets his share.
I think it's one thing to push back on repeated requests for your input/opinion outside of your role in a way that makes you a "de facto" leader. But I think it's wholly another if you're the person with the best insight, and there is need for your knowledge to be shared. Coders are knowledge workers, not widget makers - they're paid for what they know and can do with that knowledge. This doesn't need to mean you become a manager, join committees, get added to ever-increasing cross-functional project teams.
> But I think it's wholly another if you're the person with the best insight, and there is need for your knowledge to be shared.
But what if you whole day is doing just that? and you just want to spend some time writing some code? Companies are always in need of people to write the code, so there will always be other jobs, obviously it won't pay as much, but self fulfillment is important.
I'm with you, the trade is about theory building, removing ambiguity from requirements, and the update of these, code is just a tool. Still it fells nice building something, it feels nice to see something you build working in prod / to customers. Once base needs are met, it's fine for people to not want more responsibility than necessary.
> , but to refuse outright to give advise or share the experience
I think there's mentoring and leadership. These are different. I sure can mentor and help people to better think/program but don't ask me to push a team to meet a deadline they don't want to meet because they warned the marketing department 2 months before that they wouldn't do it. Been there, done that. Once in that position, you're pushing people, you become the bad guy and you have to explain that it's "for the good of the company, because they have to see the big picture, etc", IOW "screw you, I'm the boss". For that you need to be crazy enough to think that what you want is more important than what other humans-like-you are. OK, leadership is not always that and most often, you have to gather enough trust from your team so that from time to time, you can be a pusher. But if you don't have trust and you are always pushed to push, well, welcome to hell, and say goodbye to your health.
It's very different than "let's work together to find the best possible way to solve a problem, taking all the necessary time to produce something reliable".
> I feel it's completely acceptable to wish to stay in an IC position, but to refuse outright to give advise or share the experience (it's hard to tell from your short paragraph) seems... odd?
I think it depends on how much time they expected him to take out of his days. My girlfriend resigned from a job after becoming a go-to person for everything and everyone. It caused her to not have time for her own work, effectively being way underpaid, and being stressed all the time.
Yes, this happens. If one behaves like a pleasant, helpful individual (as one should!), it's a risk. There are only so many hours in the day!
My advice for any such person is to find a way to redirect questions to other capable people (when you're overloaded), or to reframe answers to be more educational. I'm not perfect at it but I'm trying.
Some helpful tips:
- If you're going to give someone instruction, ask them to share their screen while you walk them through the steps. They are far more likely to remember it this way.
- Avoid short answers. Be annoyingly informative when appropriate. Yes, I'm happy to tell you about XYZ but not without giving you way more than you bargained for!
Consider these scenarios. In each scenario, which option would you pick?
A: Look at my notes and figure it out for myself OR get an answer from Annie in 5 seconds
B: Look at my notes and figure it out for myself OR be accosted by Annie for a 30-minute video call where I'm asked to screen share my way through the steps
I think B is more likely to produce self-reliant teammates.
It can be explained by social anxiety issues, as these people typically prefer to sit in a corner coding and be left alone. Probably a self-reinforcing condition that's difficult to get out of. Just one example I can think of.
This is how toxic middle management is born. Management is not seen as a skill of its own but as a title that obviously everyone should strive for.
Also, "acceptable"? By whom? Why should I care what they think? I want to be engineering software. If they don't like that, they can either deal with it or let me go. Good thing there's plenty of developer jobs as well as corporate bozos to take the coveted management positions.
Bacs in the UK will alert the account holder that a debit has been set up, but to set it up just requires knowing the sort code (routing number) and bank account number. Much like ACH.
The account owner can at any time go in and cancel that mandate, but they do not have to pre-approve it have it set up.
I imagine the free plan also doubles as a trial for a paid subscription. Moving issue trackers can be a hassle, so having unlimited time to test out the workflow and features for a small team or project makes good sense, and if you decide to switch it should be easy enough to upgrade.
I can't know where you're working or worked, but please don't think that this is every tech job in every company. There are plenty of smaller businesses doing great work where you get to have your say, good colleagues and some (at least) moderately interesting problems to work with.
My last 3 jobs (over 10 years) have all been with companies in the size of 30-50 people, with 20-50% being product/engineering, working on a SaaS product. My jobs have been nothing remotely like the Silicon Valley TV-series, so I'm quite surprised and appalled when people say how spot on (even if it's a mocking caricature) the show is. And your description of Dilbertesque politics fall very much in that same category.
Will smaller companies have the Big Engineering Problems that FAANG companies have? Of course not. But there's a huge middle ground in lots of different sectors. I'm working for a company that makes a platform for childcare centers, and we have a ton of challenges and opportunities - not what I'd expected 10 years ago. But the work is rewarding, even if I don't get to have a lot of challenges revolving super hard algorithms, huge data sets or whatever else might be all the rage. Most of our challenges is scaling on a budget, nurturing expertise in different areas in a 10-person team, translating feature requests between customer lingo to something we can implement, and many more similar not-wild-and-crazy tasks.
I do feel lucky, but I also do not feel like I was lucky and somehow found three magical unicorn companies to work for. And there's plenty of things that could be better, and I could make more money working at bigger companies but in my mind it's not worth the trade-off.
I have always worked with smaller companies as a rule, somewhere between 5-30 people usually. I don't live in the valley, so the startup game isn't even on my radar, and the companies are already making money solving problems so all the VC infused "Change the World" attitude isn't required. I don't have to care about IPOs, stock options or whatever.
There are still so many interesting problems to solve at smaller companies, often really niche problems that have no or little prior art meaning you get to really break ground. You are also tailoring software to work on problem sets of an entirely different domain to software. In FAANG style companies you're writing software that solves software problems, which is a layer of abstraction too far for me personally.
Being smaller companies they're often involved in the community as well. Software is so often ephemeral and disconnected, there have been years of my career where I never spoke to anyone who actually used my work. I'm not sure the client always tested it either, so it could feel like I was writing software for no-one. It is nice to be connected to the real world and users/clients more directly.
I really don't believe that to be true. For our application(s) at work, the database is always the hardest part to scale and tehrefore also the biggest performance bottleneck, and the difference between good and bad SQL can be magnitudes of order of performance impact (on the query itself and locking up the DB for other queries).
Only in a "Every database has 2 TB of memory and 64 cores"-world is SQL (and database design) a negligible skill.
Having done something similar to transcode h264 to fragment mp4, there are a ton of pitfalls, weird settings and flags that need to be set to get a "correct" output that will play in most players. FFmpeg/libav provides a ton of functionality, but sometimes it's like reading javadocs, where you get the interface but have no idea of what to put in.
Related: In Denmark (where I live), we have an officially designated "NemKonto" (translates to "EasyAccount"), which is where most employers, public institutions, etc. put paychecks, payouts, etc. automatically. So if you change banks, you can simply designate the new account your official NemKonto, and the money will automatically be routed there - no need to contact anyone.
This, in addition to how easy our PBS (DK version of ACH) is to use means switching banks is something that can be done easily. I know of people who will regularly contact 5-10 banks with their current mortgage details and ask for a better deal, and then go back to their current bank and tell them "match this offer or I'm switching".
We also have a simple interest on overdraft (usually 8-15% annually on any amount over draft), though excessive overdraft will get your account locked. But beyond that, no fees for hitting negative $0.05. Is there any US bank that offer a similar fee structure? I imagine people would migrate in droves if that was already the case.
> I know of people who will regularly contact 5-10 banks with their current mortgage details and ask for a better deal, and then go back to their current bank and tell them "match this offer or I'm switching".
That's common in the US and has nothing to do with ACH in any way. That's a transaction where you likely would not use ACH at all and would use a wire transfer.
> Is there any US bank that offer a similar fee structure?
Yes, there are many. One of my banks, Capital One, calls this "Overdraft Line of Credit" and the current interest rate is 12.75%. They also offer "Next Day Grace" where you have a day to cover the overdraft and "Free Savings Transfer" where they just transfer money from your savings account as options as well to avoid overdraft fees.
I read this article a few months ago about being a Principal Engineer, https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-e..., and ever since it’s been my designated career path / plan. I am in the lucky position of working in a small-but-growing team of developers, so I get to choose my career advancement and have support to follow this road.
I think a principal engineer is the right mix of (still) developing, planning, mentoring and potentially leading small teams, while staying out of a full-on managerial role.
Which rewards? If it is salary, at least for us (I work with the author of the referenced article), we strive to keep those levels the same on the technical and managerial track.
I hopped between lead -> manager -> lead and I agree, though it’s informative to see the problem approached from both sides if you can stomach a manager stint (I had much trouble). Lead/Manager pairs have roughly the same success metrics IMO but split responsibilities and focus areas so you’re definitely right there, in my experience manager/lead is the same level on different career paths
If you ever decide to try the manager route again, look me up. My email is in my profile.
I do free one on one mentoring for managers, and my business also has a manager training program we run twice a year that really helps people perform better in the role. A lot of studies say some people aren’t “meant to be managers”, but I really believe that’s the exception not the rule.
At my previous job, we had Fastly as a potential new CDN provider set up against our existing CDN provider and two other new potentials. After a few rounds of calls for bids, Fastly won out.
Based on my experience with the other providers they were also, by a large margin, the most modern - it felt like moving from a 2008 integration to a modern, fully RESTful API with great documentation and decent UI.
This is all anecdotal, but they did combine a great technical platform with great support. If transit prices are the same or similar for all providers in that size category, they have to fight on features and support instead.
It's acceptable to want to stay in a specific role, but I am not certain I feel it's acceptable to eschew an increasing responsibility or mentoring role as you gain experience. That way lies the "genius programmer that works alone and writes code no one else wunderstands".