5 Lessons I learned the hard way from 10+ years as a software engineer
Posted by xxjcutlerxx@reddit | programming | View on Reddit | 130 comments
Posted by xxjcutlerxx@reddit | programming | View on Reddit | 130 comments
Brilliant-Sky2969@reddit
Get the best code possible right away, you won't have time to change it later.
ReasonableLoss6814@reddit
My philosophy:
Get it working
Get it working well
Get it working fast
Each phase may be anything from a rewrite to a simple refactor. “Get it working” is code your coworkers may never see; it’s experimental, bare minimum code to understand the solution domain. In a fast paced environment, you may be tempted to push that code — many do — but you don’t have to.
zelphirkaltstahl@reddit
Interrupt!!! Wild management person appears!
"But it is already working!" Choose one:
Choose boss battle and continue!
ReasonableLoss6814@reddit
The idea is that your manager (or team) never knows about that first step. You just use that first step as a reference implementation and that’s the one you submit.
zelphirkaltstahl@reddit
I understand. Though what that says about teamwork and the atmosphere at work ... Yeah, not sure I would like to work in such an environment, where I have to hide my work. Certainly a method of coping in bad environments though.
-Y0-@reddit
Eh, depends, sometimes making it fast requires a major rewrite.
ReasonableLoss6814@reddit
That's literally what I said :)
-Y0-@reddit
Another thing to consider, often trading accuracy "making it right" conflicts with "making it fast". You can trade off edge cases for faster parsing, like what simd-json did. It will accept some mishaped JSON for slightly faster parsing speed.
ReasonableLoss6814@reddit
I never said “make it right” there is nothing about making it work right.
Make it work: this is your first attempt/draft. It’s about discovering the domain.
Make it work well: this is about code quality, handling errors, “productionizing”
Make it work fast: this is about optimizations and not micro-optimizations. Adding indices on tables, queries, big-O type stuff.
-Y0-@reddit
No, you said get it working/well/fast. In that order.
Sometimes to get fast, you have to start over. Sometimes that's not enough. Sometimes you need to start fast from scratch.
Baal_Kazar@reddit
Never put the first MVP into production.
snarfy@reddit
You change it later in the rewrite / 2.0 version. And this time, you over engineer it and go way over budget and schedule. Then you make the 3.0 version, but this time you are smart to not rewrite it, and instead just delete half of the 2.0 code.
Glizzy_Cannon@reddit
No, get a viable working solution right away, optimize later if necessary. There are caveats to this like overall architecture but even then it's best to ship work in a timely manner that may have some brittle code rather than take 5-10x the time engineering something perfect and robust
bwainfweeze@reddit
You’re both wrong. There is no “later”. Later is the domain of new requirements, which have become “now” and jealously guard their time against “then”.
Later is a lie you tell yourself to feel better about cutting corners and recast the consequences of doing so as bad luck.
Do enough now so you can live with the recriminations later.
(Thinking in terms of MVP at a place you’ve worked for two years is asinine. )
Rudiksz@reddit
After 10 years as a software developer you learned 5 *generic* lessons that have nothing to do with software development? All of them banalities? This reeks of HR bullshit.
circularDependency-@reddit
It's basically just something this guy puts on his C.V. to show employers how good he is at his job.
-Dargs@reddit
It's a blog post. Did you expect something useful?
solarview@reddit
What would be useful in your view - do you mean advice specific to a particular technology or programming language?
vladimir_sn@reddit
What if you don't really want to grow your career? I mean sure I want to know more fun computer science ideas and see which ones turn out to be useful but I have zero interest in going beyond staff - the amount of bending you have to do just isn't worth it?
Jmc_da_boss@reddit
Amen, balancing this concept is one of the most important things to learn
greshick@reddit
As the lead engineer at a small start up, I have to prioritize the now, ie cut corners to get stuff out, to make sure I have the ability to fix them in the future because the company still exists to fix it. It is painful at times but its the job.
zelphirkaltstahl@reddit
Plot twist: That future never comes. Your team is never given the time to fix the broken stuff. Moaar features last week please!
Jmc_da_boss@reddit
Anyone can write code in a perfect world. You are paid to operate in the constraints of the real world
PsychedelicJerry@reddit
OK, this is more focused on a leadership path, and if that's what you want, I'd say this is decent. The only one that is probably focused on SWE is the one about efficiency - too many devs want to focus on levels of efficiency that will never be needed.
The last point about telling management they're wrong is just plain terrible/stupid advice - ignore this one if you want to do well in a job. If it had been worded differently like trying to persuade management to take a different direction, I'd buy it. But telling someone they're wrong just closes doors most of the time. Early on, I was all for telling management they were wrong (from my PoV) and regardless of the approach I took, it only eroded their trust in me. We have companies that aren't looking for the long term, so any decision that helps management in the short term, is to them, the correct decision
PhysicalMammoth5466@reddit
Same thing happened to me. My boss didn't have reason to fire me outside of not liking me so he wrote down every bug I made over the next 3 weeks and hr fired me
PhysicalMammoth5466@reddit
> Telling others (especially leadership) that they are wrong is harder but worth itTelling others (especially leadership) that they are wrong is harder but worth it
Shit advice, that one got me fired
Tobi-Random@reddit
My biggest surprise was when I realized that quite a few software engineers tend to not be aware how inefficient they are by focusing on details too much. It's like they think they have unlimited time to find the perfect solution. At least in an agency context you have to keep an eye on the budget.
Sbsbg@reddit
It's not just the coders that have these tendencies. Also testers do this. I work as a professional programmer on a large machine manufacturer. The amount of testers that get offered when I say that this particular bug that they found is not important and will have to wait for the next release, is astounding.
FrzrBrn@reddit
During the dot-com boom years I was applying at a company that had a number of both software engineering and QA positions open, so they had candidates talk to several people to see where they would be a good fit. I had the QA manager explain this, that they were the user's advocates and so pushed for every single issue to get fixed, no matter how minor. I replied that it was an engineering/management decision on how to prioritize bug fixes. She didn't particularly care for my response, so it was a good thing I was going for a development position, but that stuck with me.
matthieum@reddit
I had the chance to work with a good Q&A, and they were very good at placing themselves in the user's shoes, and at understanding how the product was used and thus the impact of each bug.
We had daily stand-ups (SCRUM, I know...) in which they were included, and every new bug they opened, they'd be able to explain how urgent/important it was compared to the others.
We didn't always follow their prioritization -- sometimes a low priority bug was adjacent to something being worked (bug or feature) and thus it just made sense to tackle it regardless -- but having the prioritization, and a clearer idea of the impact on users, was VERY useful for decision making.
lunchmeat317@reddit
This actually isn't a bad thing. That type of ideology and pressure can work well when balanced correctly.
Fennek1237@reddit
For me it's mostly the business side. They have no feeling for when to stop with requirements or how important prioritization is.
Pepito_Pepito@reddit
At a previous job, I worked on a 6 month project that lasted the entire 5 years I was there. It's started as a simple background service with a single purpose and bloated into something with a full blown UI, custom scheduling, web APIs, multiple redundant databases, etc.
CherryLongjump1989@reddit
They are very good at deprioritizing work when it's their own ass on the line.
Buckus93@reddit
"When I press these three keys at the same time, at 12:01am on Tuesday mornings when the moon is descending, I can recreate this bug."
Unique-Row4309@reddit
I worked at a place where (and I don't remember why) we had to address every issue before our mobile app was added to the store. It was frustrating and annoying as so many of the issues were very tiny things that would probably never happen.
However, when the app was introduced to the store, it was rock solid and it never crashed or caused issues for the users.
Tobi-Random@reddit
Yes you are right. I've also seen people spending a vast amount of time writing simple emails just to find the "perfect sentence".
morglod@reddit
And on the other side company lose 10x more time on working on with "just make it work" code
If you want to do smth later, you will never ever do it
Should keep balance on when you really losing time and not making unsupportable garbage
AforAnonymous@reddit
"Just make it work" creates the worst security nightmares
WingZeroCoder@reddit
And usability nightmares once it makes it to actual users.
And maintenance nightmares once you have to try to implement said security or usability.
Basically it’s nightmares all the way down.
lacronicus@reddit
the trick is to waste that 10x when you have 20x the cash to burn.
if "pretty ok" can get you to market, go with that.
morglod@reddit
I saw like 10-15 companies that died this way
lacronicus@reddit
As opposed to how many that failed because they spent too much time on a bad idea?
morglod@reddit
It's not about ideas and it's absolutely different talk
I'm saying that trading total acceleration for small but fast goal is bad for product company and modern managers can't understand it at all
Who cares what idea you have if your development speed acceleration is negative? After some time your product got to the point where you release "we changed button color" update in one month. And it's not just words, it's our today reality. And main reason why a lot of software is such terrible quality
savunit@reddit
This is the true challenge to the entire thing, which is understanding risk, maintaining, and time constraints.
There is a bit of a risk vs reward problem that happens with how people are also measured with success at a company.
Anytime your goals are too weighted to one side of our many responsibilities, management itself doesn’t know how to keep a balance.
CherryLongjump1989@reddit
It's challenging in practice but simple in principle. Most businesses come to embrace No Deploy Fridays after a few software bugs go unanswered over a long weekend, but this approach is basically what every salaried employee should be doing to defend their free time when you are not being paid overtime.
If your boss wants you to ship out buggy code, you should only allow it as long as you are not the one waking up in the middle of the night to fix it.
Tobi-Random@reddit
Yep I'm trying to avoid that by encouraging our devs to ask for more time if they can come up with food reasons like that the complexity is higher than expected and they want to "do it right". They should care about solid solutions. In the long run it appears that their estimates are getting better so we have less surprises which is a good thing.
This obviously can only work if the devs are aware of their expense and progress.
nermid@reddit
And if the answer to a request for more time isn't demands for regular overtime.
bwatsnet@reddit
Yep this is the pit most organizations find themselves in over and over again. Code that nobody wants to work with so it's brand new code every year or less. Micro everything because it's all garbage and you know it'll keep getting replaced.
shoot_your_eye_out@reddit
I had this same surprise at ten-ish years.
At twenty? Slow down a tiny bit to make sure you’re sprinting in the right direction. Moving fast doesn’t help if you’re building the wrong thing or erecting a complete pile of trash that you will never have the time to correct.
It’s a difficult balance.
dalittle@reddit
I separate design and implementation. If I can't write what I am going to build in a set of use cases and other docs then I can't build it. Almost all folks I have worked with will just grope around in the dark trying to figure something out and then when they do it will have been refactored like 30 times (taking forever) and the code quality is really low. I get consistently asked why I am able build projects quickly. I collect requirements, make a software spec, then move to agile and most of the time only have to implement it once.
Full-Spectral@reddit
I'm sort of the opposite. After 35+ years, I've realized that, for the very complex stuff I work on, that I will never, ever foresee enough, and that I'll STILL end up trying a good number of approaches, so I've learned to just accept it.
Of course I have an idea of where I want to go, but no amount of planning will avoid a lot of iterative steps to refine it to its final evolutionary form (well, the first final evolutionary form anyway.)
It may seem chaotic to the observer, but my process is basically an extended form of divide and conquer. And, in the end, I won't have to guess if I was right, I'll tried enough options to know I'm as close to right as circumstances allow.
This is why I love Rust now. I can refactor like crazy with complete confidence I'm not introducing crazy memory or synchronization errors.
OrchidLeader@reddit
Well put and so true. I think a specific kind of planing helps a ton. I just wish I had a better grasp on my process, so I could teach it to others.
I’ve had people say the same thing about me building things quickly and it working the first time. I see their process as constantly throwing things at the wall to see what sticks.
Planning on its own doesn’t help because some people will get stuck in analysis paralysis that mirrors what they would have done if they had jumped right into coding. I think I kinda do the same thing but just in my head and maybe way faster? I don’t know… Could also be related to how I’m always trying to prove myself wrong as fast as possible, makes iterating over ideas quick.
I know how to break down tasks for a computer to execute. My challenge in my current role is to break down the process for a human to break down tasks for a computer haha
shoot_your_eye_out@reddit
That’s funny, I’ve arrived at almost that exact process myself.
Tobi-Random@reddit
That's also an interesting topic you are mentioning! Once I worked with a guy who just chased the first idea he had after reading the requirements just to find out that he misunderstood some requirements and overseen others.
Being attentive and aware that requirements can be incomplete and ambiguous or maybe just you could misunderstand something is a skill I Iove to see in other people after this experience.
ZenHaise21@reddit
I am still struggling with this as a junior to mid developer, finding myself stuck in writing the perfect code piece instead of balancing speed of delivery with code quality.
MountainDewer@reddit
Get it working end to end first. Then improve the obvious hacks.
MovingObjective@reddit
Even better:
TODO: fix this hacky stuff.
meganeyangire@reddit
In one project I saw "TODO: (Name of a programmer who quit 3 years ago), fix this mess"
Plank_With_A_Nail_In@reddit
I created a function that returned the immigration to asylum ratio for my country for a given year. As a placeholder I just made it return 20% with a todo of making it work out the actual value once requirements became clearer, that placeholder is still in production today we tried to change it but the business rejected the change as it didn't return 20%.
meganeyangire@reddit
Obligatory relevant xkcd
also_also_bort@reddit
Honestly I’m of the mind that if a TODO has been there for three years and hasn’t caused any issues it should just be deleted
daringStumbles@reddit
While I get the desire for this, old todos have given me a lot of insight into the why of some really backasswards solutions before. Todo aren't instructions to me, they are a window into developer intentions, and I will happily and gladly leave them everywhere and tend to not delete them unless the code around them changes.
JordiHey@reddit
I saw this "TODO: I dont know what to do on this case, i should probably ask someone" on 3 - 4 else blocks that only had a logger instruction.
All of these TODOs were commited three years ago, and I tried to complete them but was told that was out of the scope of my current task. So they likely remain there for a long time.
sgtkang@reddit
Make a ticket 'Fix this horrible code' and label it as 'Technical Debt'. Make sure to bring it up the next Backlog Refinement meeting so you get points for 'caring about stuff' and 'having constructive opinions'. Spend a few minutes discussing it with your team. Conclude that it's not a priority but worth keeping on the backlog.
Economy-Beautiful910@reddit
Make it work -> Make it right -> Make it fast.
JarredMack@reddit
The good news is that the only difference between a mid and a senior is that a senior can (mostly) make these judgement calls from experience. You'll get there
WeeziMonkey@reddit
Instead of thinking in binary terms (bad code vs perfect code) I like to think about it in three levels:
Bad code - works, but is bad
Good code - good enough, takes 1-2 extra days
Perfect code: takes too long
Tobi-Random@reddit
"perfect code" is not always reachable in a sensible amount of time. It has to be well structured and understandable so that anyone can improve and extend in the future. Avoid hacks, workarounds and shortcuts as long as possible.
As long as you find a solution end to end in sensible time you can clean up in the remaining time.
Sometimes you find yourself in situations where you just need more time to do it right eg. When the complexity is higher then expected. As long as you can identify it and, again, are aware of that, just talk with the manager about the necessity of doing it right.
Just be aware of the expense you put into a solution and that it is reasonable. This will get you pretty far
morglod@reddit
You should keep balance and think about goals. Sometimes it's good to take more time to craft something better, sometimes you just can't make smth better, sometimes you should do smth very fast not looking at quality
In big tech if you think you will do smth later, you will never do it, because usually product managers are too stupid to think about tech debt and they are focusing on fast results rather than future
And after having a year of fast results they got product which just can't be supported or extended at all
imp0ppable@reddit
One of the most annoying people I ever worked with was this solutions architect who would just constantly but into discussions with "DON'T WORRY ABOUT THAT NOW JUST GET SOMETHING IN!!!"
It was annoying mostly because he was usually right, in any case most technical discussions are premature and you end up doing something else anyway.
It was also slightly annoying because he couldn't architect a lego house but hey ho.
Kurren123@reddit
I think I’ve seen more “just make it work” code than “focusing on the details too much” code.
turbo_dude@reddit
Good enough is good enough
vincentofearth@reddit
I think it's because most engineers haven't (or refuse to) really internalized the business's goals instead of their own. As an engineer, you're much more concerned about building the best thing possible, so it's easy to lose sight of the fact that the business has a related but separate goal of shipping a product.
Tobi-Random@reddit
I agree with that. Plus the goal is also mostly "with the least amount of money". By that I don't mean cheap but nobody likes wasted money right?
There is also a different Facette I've seen: the engineer always went with "the fastest solution" while the business goal was to find "the most efficient solution". Not always is the fastest solution the best because it can waste resources. There can be a much lighter solution with some downsides like being a little slower but utilizing the resources better.
At scale this matters!
Cthulhu__@reddit
This is something you grow out of when your meticulous code is discarded after a few years because there’s something new that replaces it entirely. Some good advice to keep in mind: code is a means to an end, but for some it is the end.
TyrusX@reddit
My company has the most pick engineers. 4 years in we have 20 users and nothing works. it is insane.
scyber@reddit
"Perfection is the enemy of completeness"
That is one of the biggest lessons I learned.
agumonkey@reddit
And how easy it is to diverge bit by bit into making something that will legitimately have no value for users. Saying this as someone who did that way too much before.
amakai@reddit
I think this is one of the drivers of many of software development. It's sort of a puzzle - making your code "perfect". And once you do it and are satisfied with yourself - you get a nice dopamine hit.
So I don't think those engineers are "unaware how inefficient they are", they just want to solve that puzzle along with doing their job.
Tobi-Random@reddit
Yes and no. While you are right in your explanation (I've been there as well) you are describing a different situation.
The situation I described exists as well. I've talked with those devs and after suggesting to write down estimates before they start working and tracking their times they told me that it was surprising for them seeing how much more time they spent then they have expected. For juniors it's pretty common when they leave university and start their first job. I believe it's because in the university they had no time constraints and therefore no need to keep an eye on that as long as they finished "before reaching the deadline".
seba07@reddit
Exactly what I see as well. For some people this seems to be more like a hobby. After the third refactoring you should start to ask yourself it it really produces so much business value.
chicknfly@reddit
I’m guilty of this part of it is having the ADHD hyperfocus and the thrill of of making (or improving via refactor) a chunk of code. Sometimes the “garbage but still works” level of code is just too painful to understand quickly, and refactoring just brings that absolute joy. I worked for an agency and they loathed that, for understandable reasons, but they forgot that everybody else in the company had been there for 8+ years and knew what the code did while I was practically reverse engineering without documentation from scratch.
Anyway, people have all sorts of reasons for inefficient use of their time.
harzer_zwerg@reddit
You quickly tend to let a project become your "child" that you lovingly care for…
Tobi-Random@reddit
Haha yeah, I guess you know me 😅
UnclearMango5534@reddit
Thanks, needed this More tips or something to tell to a junior to land his first job?
Sovol_user@reddit
Some so called great website hosts are not as skilled as they say for back end coding eh. PHO, PERL, SQL, Java. Linux code or even HTML
Coneyy@reddit
Is this a quote from the blog or are you having a stroke? What do you mean website hosts? Those are programming languages, mostly. And HTML is a markup language...
Also Java has been a tried and tested backend language making up a vast majority of enterprise businesses, while SQL is specifically a relational database querying language.
I am seriously struggling to work out what you are saying, has HTML claimed to be a good backend language? Has SQL claimed to be a "great website host" whatever that means
Sovol_user@reddit
I was just speaking In general.
I've seen hosting services promise all the above and more but after they get your cash they crash your website if you load up one static HTML page, a web page that works on 20 other hosts.
OK HTML is not a computer language even though the letter L says it is. PHP and PERL are just scripts some will call them..
Back end code to me is source code that the programmer uses to make the object code that the user sees. Like this site lots of stuff you see are using what I call backed code to make them work and appear to the users.
For example maybe using HTML to use PHP which uses SQL to access all the data that gets displayed to users.
I am not trying to be too technical, I don't want to start writing: CSS, RSS, MySQL, SQL, WAP, XML, etc. or even a work around for "stop words" in SQL here.
Or asking HTML to call a PHP, (script) that calls a PERL, (script ), that produces HTML that uses CSS, (for layout), and JavaScript embedded to do something that is pure HTML, ( a computer language, because it says it is with the letter L), is unable to do.
REPEAT,,,,UNTIL forever 😀
Coneyy@reddit
tl;dr: I don't care that you don't know what you are talking about, but attempting to signal that you do by using random combination of languages weirdly provoked me enough to respond. I didn't go too technical either and kept it as far from pedantry as I could, while still responding to your nonsense. So if you want to know more or gripe about specific hangups, just look it up.
Not entirely sure there is much value in responding to this, because you clearly have a very surface level of what you are talking about; but considering it's on r/programming - I will at least type out a response and see if I either hit post, or succumb to the futility and delete it all...
> OK HTML is not a computer language even though the letter L says it is.
The letter L stands for language, not sure what about that makes it a programming language. Would you consider Mandarin a programming language? The acronym stands for Hyper[T]ext Markup Language, it's just a standardised encoding system browsers have agreed on using to display graphical UI content.
SQL is the same, not a programming language. Literally a Query Language As PeR tHe Q aNd ThE L !@!
> Back end code to me is source code that the programmer uses to make the object code that the user sees.
That's fine, but you are going to continue to run into confusion/misunderstandings - especially on programming subreddits - when you use normal phrases that exist ubiquitously across programming to just mean something you are defining for yourself.
Backend is "generally" used to refer to the code that handles the query language interfaces and data/server stuff. Frontend is "generally" the languages you use to manipulate the UI/Graphical elements like HTML. e.g. Javascript.
Some attempt to do both like PHP, and generally speaking there's nothing stopping any Turing Complete language from manipulating the HTML's and SQL's of the world, but some do it better than others.
This leads me to my final point I want to respond to:
> I am not trying to be too technical, I don't want to start writing: CSS, RSS, MySQL, SQL, WAP, XML, etc. or even a work around for "stop words" in SQL here.
Then why list them at all? You clearly were trying to be technical, you just have no idea what you are saying. You are signalling random combinations of acronyms and languages that you have read exist under the hood of whatever website builder you are referring to. But you don't know what they do. Like you even listed RSS in there lmao
Plank_With_A_Nail_In@reddit
SQL has case statements that can make decisions, those decisions can even run other SQL via subqueries. So its partly a programming language.
Coneyy@reddit
Yeah I had a few pauses about the semantics and what level of pedantry I should try to account for, but figured it was all yelling into the void. The main message behind SQL being you aren't ever making software in it. It's a language to interface with a DBMS. And while making raw SQL queries is a relevant skill. Its a tiny fraction of the queries made globally every second through some """actual""" programming language acting as an ORM
Sovol_user@reddit
PHP typo
Brief_Departure3491@reddit
lame and stupid. shameful you would write something so vapid after 10 years lol
gammison@reddit
Seriously.
This is almost never worth it and results in your career being torpedoed by the people you said no to.
The important thing is documenting everything so that when something goes wrong you can show you pushed back.
data_owner@reddit
Some guy wrote some time ago that he doesn’t tell others they’re wrong unless he’s explicitly paid to do so and that it changed his life for better. I tend to agree with that.
iamdestroyerofworlds@reddit
It's much, much harder to tell yourself that you're wrong, and it's infinitely more worth it than telling others that they are wrong.
solarview@reddit
This sort of thing really depends on company culture. You should be able to do this, so maybe people reading the article could potentially be in the position to shape culture and so the article could be beneficial for their understanding.
syklemil@reddit
There are huge some cultural differences there, I think. E.g. here in Norway it'll be relatively common, while we also get stories of attempted outsourcings to some Asian countries that sound like italian strikes as apparently even just asking for clarification seems to be considered out of order.
IMO management should encourage honest feedback so bad decisions can actually be avoided. Surrounding themselves with yes-men won't lead to good quality.
Brief_Departure3491@reddit
Yes same. I have learned the exact opposite lesson after 15 years.
Dont disagree. Don't engage. Keep your head down and avoid the loud idiots who want to tell you how to do your job
Tejodorus@reddit
You write: But, titles and past achievements didn’t matter. No one really cared about my title or opinions until I proved my worth through tangible impact and adjusted to the company’s culture
What do you think about this? It is reality, I understand. But is it not wrong that people do not respect you because of your arguments? Is it not stupid that you first have to prove yourself and lower yourself down? Why is it that people can't just accept you when you enter?
MaHcIn@reddit
Do you not understand how social dynamics work?
Respect is earned, not given. Having a shiny CV does not guarantee respect.
You earn it by being friendly, communicative, respectful and reliable.
So many software engineers don’t get how important it is to be sociable and likeable over being 100% efficient at coding.
Tejodorus@reddit
Can you explain why this is? Imo, it is simpler and better for the organization when you listen to everyones arguments regardless of the person being friendly, communicative, respectful and reliable.
Even someone unfriendy with difficulties in communicating and not always being reliable can have good ideas. And if his arguments are right -- then why should he first have demonstrated tangible impact? Why not just listen to him?
hamburgan@reddit
My take on this is that it is way more mentally energy efficient to run ideas/arguments through a pre-filter. ”This person usually have good ideas so I will listen carefully to him/her” vs ”this person usually just creates problems so I’ll just disregard what he/she says”. To give a silly example, just imagine you carefully considered everything Trump said. Sure you might find some interesting ideas here and there but mostly its just noise.
Tejodorus@reddit
Yes, you could be right. I struggle with that, wondering what would be possible to change the menatiliy of minimal energy. In the short run optimizing mental energy pays out, but for the long run, I think it is suboptimal.
flowering_sun_star@reddit
Because that isn't how people work. People aren't rational, no matter how much we might wish so (and yes, that includes you and me).
And quite often an idea or change can't be demonstrated to be correct through pure argument. You need to take a chance, and you're more likely to take that chance if the person making the suggestion has a track record of having good (and successful) ideas.
Tejodorus@reddit
Wow, what a lot of downvotes. Am I the only one here that is open to new people to my team and that is interested in their opinions and past experiences starting from day 1?
carsncode@reddit
Why should they? And why would that be something we'd want or expect to change? When you're new you're a stranger, recruiting processes are highly imperfect, and levels like "senior" say nothing of specific expertise. I've worked with staff engineers who were clueless. Having to prove yourself is the nature of working with humans.
Tejodorus@reddit
Why should they? Because the new one is a human being that may bring interesting new insights. Because you have a professional relationship with your colleages; and a professional relationship is about arguments; not about social fluff. Because you want to do the best for your company -- and disallowing newbies to make impact for months or years just because of reasons is not the best for the company. It simply is not rational; and IMO, you are being paid to be rational. Private life is for social stuff; working life is for professionality.
carsncode@reddit
I think you've misunderstood - I didn't mean social as in getting a beer together or whatever "social fluff" means, I mean social as in personal interaction. Professional relationships are social. I'm not paid to be rational, I'm paid to deliver business value. It sounds like you're projecting some personal experiences onto the industry as a whole here. I'm sorry you've had bad experiences but they may be confounding your understanding of the discussion.
Tejodorus@reddit
My point is: should we all be a bit less "social" and more "rational"? I am always very open to new people because they often bring interesting insights and new ideas. Not always ideas that fit with what we do, but it is easy to find that out when you take them seriously.
I simply cannot believe why so many people are not so open. I do not see the rational benefit of not being open, and not listening to what new people can bring.
carsncode@reddit
Counterpoint: it's a cliche in the industry for a new person to join an established org and start throwing out ideas based only on their past experience without first understanding the context they're coming into, which takes time.
Tejodorus@reddit
When you mean that newbie ideas based only on their past experience (without rational motivation) should be rejected, then we agree. We must ignore that idea.
But, when you mean that a newbie must also first understand the context even when he has rational arguments, I disagree.
Even without understanding the context, a newbie could pose an idea like "Why not do A? It has advantages B and C, and disadvantage D. Would this fit in your context?". And then you discuss the idea together: you with your context; he with his new idea. He learns your context; and together you can find out very quickly whether his idea makes sense in your context.
I really see it as a waste of time and a lack of respect to wait for weeks of months before such a discussion can take place. Openess and respect are 2-way.
carsncode@reddit
Why should anyone expect a suggestion made without the benefit of context to have any value? Or, indeed, expect it to be something no one else has thought of? The kind of ego it takes to wander into a new role and assume based on nothing that all your ideas are fresh and you don't need to understand any context to propose a solution is a huge red flag. Respect is two-way, and that kind of behavior is disrespectful to the team you're joining.
Tejodorus@reddit
The world is not black and white, there is gray in the middle. One should be able to bring in ideas in a subtle way early in the process, right? And just politely check them? Or do you really believe that new people will NEVER have anything useful to contribute?
Sure, there are people that wander into a new role and just assumed based on nothing that their ideas are fresh and do not care about the context.
But there are also others that do have fresh ideas and do care about the context. Treating all of them as having an "ego" is, IMO, not fair and not giving you the best for your organization.
We are going in circles.
ItWasMyWifesIdea@reddit
No, it's not wrong. You prove yourself by making an impact... Improving the product, execution, something tangible. And making an impact is what matters anyway, not arguments.
What do you mean by "lowering yourself"? The best SWEs I have known don't see any task as beneath them. They'll improve documentation, fix a small but nagging bug, remove a compiler warning... Whatever the product and the team need.
Tejodorus@reddit
Lowering yourself (and I quote from the blog post): "For quite some time, work at a level below the one you are hired for.".
I do not think that this should be necessary. I think people (and SE in particular) should be open to new people instead of closed. Listen to them and their arguments without forcing them to lower themselves to become respected.
ItWasMyWifesIdea@reddit
Part of the point isn't just earning respect (though that's part of it), it's being humble and learning. The new team is not going to be the same, so your previous ways of working might not all work and you may learn new things from the new team.
As for earning respect. Think about it from the other side. Have you ever seen a new person get hired in and want to change everything without first proving themselves? It happens a lot, and a lot of those people are wanting to make changes not because it is necessarily better but because ot is what they are used to. It's natural that teams are skeptical of newcomers who want to make major changes without first understanding their new environment.
Tejodorus@reddit
When people walk in that want to change everything, I always listen to their arguments, have a fair discussion about why we do what we do, and then see whether his suggestions make sense. And if they are just another way of doing it -- without further argumented benefits -- then we should not do it.
What amazes me is why respect matters. If the same person has the same ideas with the same arguments on day 1; and the same ideas with the same arguments at day 100; it would not be rational to accept his idea at day 100 but not at day 1 because the idea is the same. Worse, it would be strange to accept the ideas at day 100 if he had gained respect; but to reject the same ideas at day 100 when he failed to get respect. It is just not rational and does not make sense. And if you do accept the ideas after day 100, you've lost 100 days for no reason.
write_now_tech@reddit
Devs really have this tendency to dug in to the rabbit hole.
Btw, dev here. Just learned the lesson the hard way
turbo_dude@reddit
"I want to do it my way and not follow a standard that the team uses."
"I want to use technology xyz because it sounds exciting and want it on my CV/resume."
"I don't want to write any documentation so I will have the special knowledge and become all powerful"
If that's you, just fuck off and hand in your resignation already for the sanity of the poor bastards who have to work with you.
write_now_tech@reddit
Couldn’t agree more
Skull0Inc@reddit
It’s the nature of tech to be dug in a hole, or digging yourself out.
cobamba@reddit
"Gourav reached Staff Engineer in just 8 years" wow! I have to his takes and I'll be the next Linus
boybeaid@reddit
Lesson 6: The real hard way is reading about someone else's hard lessons, knowing full well I'll make the same mistakes anyway
b_curious@reddit
The things is, everyone needs to learn by their own journey, there can’t be any generic fit for all path.
Accomplished_Yard_62@reddit
The 6th lesson which is may not be valid outside but valid in India is Be the Yes Man of your boss even if you do what is direct opposite of what your boss tells you.
bwainfweeze@reddit
That is a chronic culture class with North America. If we hear “yes” and you do something else entirely there’s gonna be problems.
India and Chinese culture think it’s terrible form to contradict your boss in front of witnesses but have no problem contradicting them behind their back. We find it infuriating and duplicitous.
Obie-two@reddit
Great article. One of the best on the topic. I don’t know how many times I’ve seen phenomenal devs pass through our org that failed these lessons, and felt like promotions or opportunities were owed to them they did not earn for one of these reasons or another.
I would maybe add honest recognition of others, or sharing of credit is also valuable. All the people I worked with 10 years ago at my company are now in the senior roles along with me. And if you stepped on people to work your way up, they will remember that.
toomanypumpfakes@reddit
This is actually a great article that aligns with a lot of my experiences and lessons learned as well. Nice!
I think the first point about selling yourself with tech talks is a great one. I’ve always liked giving tech talks because I like talking about what I’ve worked on. I’m not great at distilling my work into some life lesson for other engineers, but I can tell a good story about why the project I’ve worked on is cool and why you should think it’s cool too.
I know multiple engineers on my team who want to be promoted but don’t get out in front of the org enough and I always suggest to them to give a tech talk and am surprised when they don’t want to. It’s actually a perfect low stakes way to get your face out there: it’s low stakes because you’re not defending a proposal, you’re talking about what has already worked.
The other tip I’ll add that I’ve learned is that work is an iterated game. When I was younger I would spend way more time than I had to polishing up my design docs, talking to people one on one, then finally scheduling The Big Review. But the thing is that you’re going to get a ton of feedback and have to schedule another meeting no matter how perfect your doc is.
Now I put plenty of effort in up front coming up with a couple options in a doc or a prototype, but just enough to set up a meeting where we can then have an informed discussion about direction. Once that’s settled the details can often be worked out asynchronously or in smaller forums. You also don’t have to worry as much about your perfect ideas being shredded and your ego hurt because the discussion is framed as being collaborative from the start and you didn’t spend days on crafting your perfect baby.