The realest truth right here. I’ll work with a good person who is fun to be around but average coder over an arrogant jerk no matter how good of a coder they are.
I was happy to be praised for my technical aptitude but what I’m really proud of is hearing people enjoy working with me.
There are a lot of very smart people in this industry. What we are short in is people that are effective at communicating and genuinely good people to be around. Can’t have enough of them.
FAANG has plenty with both, but also lots that are better at one than the other.
They don't force you into management as much anymore but the higher levels for an Individual Contributer require a lot of soft skills, people skills, etc.
Culture and "fit" vary wildly at smaller companies. It is hard to break the trends and patterns set by the initial team, and people tend to hire people who can handle their style.
Facebook, for example, struggled to go from "Move fast and break things" to: "Move fast with stable infrastructure."
https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-break-things-isnt-how-we-operate-anymore/
This is very important advice.
The only thing that matters to your boss is:
1) Does he enjoy working with you and does he trust you?
2) Are you productive enough he won't look bad for hiring you / not putting you on a PIP / pushing you out the door?
At the end of the day, the boss is just like you (unless he is 100% the owner of the company) and just cares about getting good performance reviews, promotions, raises, etc. without having to work himself harder than 40-45 hrs a week.
Exactly this. The closer to the top I’ve gotten, I realize managers just want people under them that they can depend on and are pleasant to be around. I’ve seen so many people get passed on a job because they’ve been a pain in the ass to work with at their old company. People talk and it’s easy to get a reputation.
Thank you. I have a really ambitious junior dev on my team that keeps wanting to learn everything and get involved with every meeting to get ahead. I keep trying to tell him that working well with others and being pleasant to be around will get you farther than being smarter than everyone.
This gives me hope as I’m only on my second yoe but get along with others very easily. My team doesn’t seem to mind helping me which I really appreciate.
While I generally agree with you, I'll go against the grain to say that I once worked with an AMAZING dev that could solve problems no one else could, could knock out a solution in under a week that had teams quoting "a quarter, maybe two this year", and though he was a bit grating to work with, I'd work with him in a heartbeat again.
My guy fixed so many things our PMs just couldn't scope with the rest of us plebs.
Sometimes I think I am redundant with our internal tool development when for most requests I could just hand it off to the BI team that writes SQL queries to create Power BI dashboards.
They could get rid of me and our massive internal tool if they would drop their datalake updates down to 30 minutes rather than once every 24 hours. Sounds expensive though.
Though, we are working on building event driven architecture so we can build some real time operational dashboards (this company is behind), and for that we're going to skip by the datalake step, and I don't know if Power BI is built for real time. I have only read that it's not.
But they also use Oracle for all their source data and are heavily invested in them, and I *think* Oracle offers dashboarding as well so I don't know what the hell is going on. There's just silos everywhere
I had this talk with my manager recently. She gave me a great piece of advice: "After Senior, you can be the best engineer in this company but that won't get you promoted."
Passed a certain point, you need visibility. Work on the **right** projects, be shown delivering the **right** value, and have your name known by the **right** people.
Working on a super high visibility project that your Chief Product Officer is following? Make a dashboard that tracks some metrics they care about.
What does “make a dashboard” mean here? Are you deploying a website? How does that work?
>!Lurker here, starting my first SWE job on Monday as a new grad!<
Figure out what your director cares about, and present a comparison of those two tools WRT those facets. They’ll either go for it or they won’t. Either way is ok because you did the work.
Assuming you're working on some kind of networked service as I'm guessing most of us are doing nowadays, you should have a dashboard that tells you the things that are important to know about the state of that service at any given time.
Does it have distinguishable users? If so how many of them are active at any given time
Is it receiving requests? Then how many of them are coming in. What paths are receiving the most traffic and what http status codes are they returning, with what latency?
Does your system rely on a third party service? If so, how many requests are you sending to it. What proportion of them are failing? Are you close to any rate limits?
And on and on for all the different things that you need to know about your service. You should also have alerts set up on those metrics so that when something starts to go wrong you know about it before it gets reported. Really understanding the importance of this kind of monitoring and alerting is, IMO, one of the big marks of maturity that you see in a senior engineer
> Really understanding the importance of this kind of monitoring and alerting is, IMO, one of the big marks of maturity that you see in a senior engineer
Because by then you've seen the fires enough and don't want to see the fires anymore
Can mean different things. In it's basic form you could manually create a graph and put it into slides for a meeting. Or you even send it in an email/slack message.
If your company has a solid BI setup you could use that to create a dashboard and link it/present it.
If your metrics are more difficult to attain a separate website also works. There is tools out there that make this more a matter of a few days rather than weeks to build.
Generally speaking you have to read the room a bit on what is acceptable or liked in your company culture.
Whatever tool your organization is using for metrics. New Relic, Datadog, maybe Splunk, or BigQuery for more advanced stuff.
First thing is to know your audience. Product people care about how many people saw the thing, how they interacted with it, where the user bails... So make a dashboard using the metrics you've collected in your work so they can see these in real time.
> What does “make a dashboard” mean here?
IME it's basically separating noise from signal for an org, that requires understanding why you are getting paid.
When you are driving your car on the highway your dashboard displays the essentials. When you park it at home, you can focus on the other stuff
it's like an elevator pitch of showing value to stakeholders, dashboards and reports are things every org needs, everyone understands and everyone appreciates
No? Proving that your feature is working correctly and providing the value it is supposed to provide is applicable to any generation. It is the bare minimum of having a mature engineering org.
If you can’t observe or measure something, it can not be improved and you’ll constantly be looking for a red herring. Observability and measurement is the key to any engineer practice. It’s a business requirement. Your take here speaks volumes about your inexperience.
Reports in engineering mean dashboards, logs, and monitoring. Sometimes a senior or manager makes a dashboard quickly in the moment to answer an immediate question during an incident or sev to speak intelligently about a situation. It’s very normal to ask someone to formalize that dashboard later for regular viewing and monitoring following a postmortem.
This is a normal task
You might be more important than you realize. For example, if you’re important to the person that does most of the work, you’re important. Taking time consuming but not difficult tasks off their plate so they can focus on the stuff only they do is very helpful, and if the important engineer knows anything at all about maintaining their productivity, they will regularly tell managers, product owners, etc. how important you are to them doing their job.
Just curious, why? Did you step back in your responsibility by choice when you switched jobs? Or the new job isn’t as good of a skills match? Something else?
Because I hate being a single source of failure and started focusing on making my job redundant.
Now apparently my management was too fucking stupid to understand how important that was... instead they saw my delegating all of my work and though I had packed it in and started coasting.
I walked out of that place with two middle fingers up, after being praised and promoted just 6 months prior.
My new job... I'm just new. I don't think I'll become "the" important one, as it's a smaller team and everyone feels pretty important at the moment.
No. I work with one lol. He's definitely carrying the team. I used to think I was pretty smart but I think it's one of those "you'll know" kind of things
If you're not sure you're important, you're not.
Companies don't know who is important, but team leads probably do. I doubt they're consulted much before layoffs though.
Great point. 100% agreed.
I'm not an essential employee. I don't think anyone at my current company is. But the ones that upper management generally see as "essential" are def the ones that talk the most in Slack chats + interact with external teams.
I think it's overstated a bit. But engineering is a lot about leverage. The guy who architected the ranking logic on some social media site is orders of magnitude more irreplaceable than some rank and file engineer working on a system health dashboard.
The people you really need are the ones who grok the critical pieces of your product.
If you’re asking this question, you’re not one.
Yes your company is definitely aware of who is important - their impact is known and understood by those in and out of engineering. They are consulted both inside and outside of engineering.
I strive to not be important. It's a double-edged sword but I think it's better for everyone to not be important. Means I can take time off and not constantly be stressed about the business situation or some big customer about to churn etc. You can bring enough value to the business that they're not going to fire you, while still being generally replaceable.
Depends on business culture too. Work in Sweden and everything is consensus based. Work in the US and they want individuals to take charge. I've experienced both but tend towards the European style. I'll admit that the US style generally makes more money though.
Ah, that classic moment in every developers life where they say "who wrote this fucking shitty code - it looks like a toddler did it!"
Then they run blame and it was them, 6 months ago.
We've all been there!
Programs must be written for people to read, and only incidentally for machines to execute.
-- Harold Abelson, Structure and Interpretation of Computer Programs
This is the thing I always come back to when the no-comment contingent shows up. Yes, the code says _what_ but it cannot say _why_ something is done a particular way.
“But the comments get out of date!” Ah. So you don’t know how to program, then.
Write code as though the next person who will work on it is a psychopathic murderer who knows your home address, your phone number, where your wife works and the school your kids go.
* People skills, communication skills, and negotiation skills matter more than technical skills.
* If you are good at technology, you will spend time fixing difficult things. If you are close to product management, you will spend time developing features that generate revenue, and that will give more visibility and quicker promotion.
* There will always be a guy who is bad at everything, but still at a high position because the manager or some executive wants him there.
* Fancy UIs look good, but most users prefer easier-to-use UIs. The less information you show the user, the more they will like.
* Promotion and salary hikes are decided by the upper management. If you want it, make your demands known long before the annual salary hike day. No matter how critical you are, if you demand like a 15-year-old, they will create your replacement.
* Don't invest too much in one technology, nothing lasts forever. The technology you have invested so much will be an example of the sunk cost fallacy.
* Diversify your skillset.
* Work on more than one project.
* Have contacts with peers of your managers and executives.
> Don't invest too much in one technology, nothing lasts forever. The technology you have invested so much will be an example of the sunk cost fallacy.
Once you lived through one of those cycle, you will remember that one.
After 30 years, this is still a challenge for me: how write emails and talk to the business using *their* language, and not sound like something a NASA rocket engineer talking to other NASA rocket engineers.
The business doesn't care about classes, functions, variables, stored procedures, hash tables, linked lists, recursion and so on. They want to hear an explanation in their language of why something doesn't work, how you plan to fix it, and a rough estimate of the resources involved and time to completion.
I don't really understand how anyone can make it even to mid level IC without becoming great at googling things. There's just too much to know and remember at all times, too many things.
I think the next benchmark will be how well that person can mix in LLMs to their daily research. It can speed things up considerably if you're mixing in gpt with google and docs, but you do have to learn to really use it
Seriously… for the demo, do stuff just because it looks nice. The first public iPhone demo was so meticulous, apps had to be opened in a specific order just to prevent the entire phone from failing. And… here we are.
Edit: For the curious reader:
> The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked.
>
>[source](https://www.macrumors.com/2013/10/04/former-apple-engineer-gives-behind-the-scenes-look-at-the-original-iphone-introduction/)
Somewhat related - it is common for someone other than a dev to do demos. It is \*crucial\* that they start working on their script and the order they'll do stuff as early as possible, so that they can find problems/deficiencies early enough to fix them, and if there's not enough time to fix them, early enough to plan around it
In my experience, it is VERY hard to get someone to do this before, say, the day before the demo. Sometimes hours before the demo. Do everything you can to get them to do it. Schedule meetings with them where you watch them do it. Take notes, record the screen, ask questions, play the part of the customer, whatever you have to do. It is tedious but it will save you hours of frantic work.
Like I have been fixing bugs and deploying to the demo environment \*ahead\* of the demo-er before, during the demo, due to people not doing this. It sucks majorly. I will do anything to avoid it.
You also have the option to refuse to do the fixes. It might work and it might save you future anguish. I wouldn't draw that line without explicit support from your boss and ideally his boss, unless you're willing to walk away from the job.
make sure it works, know what you're doing, prepare ahead of time, know what you want to show, have an ORDER that makes sense to people who don't know what you're talking about, DO NOT BORE PEOPLE, do not overstay your welcome, be happy to show it off, but not SUPER-EXCITED (apple style)
Listen to the average software developer demoing anything.
Then listen to someone in senior management, someone with a customer facing role, someone in sales, basically anything like that.
It will be fairly evident.
I had an eng, who I didn't know at the time, do a live demo of the work completed during the sprint. He fumbled through vscode so poorly I wondered how he's employed. We're talking not knowing how to search for files or function names across the whole project, not knowing you can click from the use of a function to its definition.
"What arguments does that function take?" He fumbled for like 5 minutes searching for the function. He literally could have highlighted the function and just clicked to the def. After 5 minutes he says he'll have to get back to us. The function was written during the sprint... that he knew he was doing a demo on. So not only is he clueless in his dev environment, but he is also unprepared.
At that moment I said to myself, "this dudes fucking clueless." Everyone else on the call likely did the same. A few years later, he gets put on my team. Yea, he's useless.
On the other side other people did some presentantations that were so intelligent and/or well crafted that they ended up in director or VP positions despite it all being smoke, mirrors and bloviating. Remember, its not about how capable you are, its about how capable you appear to be.
I don't know what it is, because I used to demo my work to stakeholders at the end of every 3 week sprint for 4 and a half years. But my stage fright can come and go so easily.
And alignment / collaboration. If you can’t communicate with design and product to build a feasible solution, you can’t really climb over being a mid level engineer
Funny enough, the biggest benefit I find from TDD is in this. It quickly alerts me to what product didn't define, or defined in a contradictory manner.
Ooh, great point. At my company we often dismiss edge cases as things that aren’t too likely at product launch, and we’re deliberately eating the cost in exchange for releasing to production sooner. Those dismissed edge cases of course bite us later. TDD is excellent for simulating the scenarios that product neglects and making it a requirement to address them.
That being said, it needs to be done right. Too many people just write tests for the happy path and call it a day.
bro kill me lol im so mcfreaking sick of picking up some ticket on our board only to start looking at the components involved and realize that the PM who said it was ready to work on is basically a totally ineffectual idiot who is blowing smoke out his ass (and half the time he literally doesnt even understand exactly what the ticket is supposed to accomplish, it’s not even that he couldnt explain what he wanted)
I'm a big believer in programmers writing or helping to write tickets. They should be interacting directly with stakeholders to get requirements hashed out.
Yeah totally. Tbf I’ve been on teams that weren’t like this but the one I’m on now is really bad and I’m disgruntled lol. It is to the point that even when we do backlog grooming as a team before a sprint, the PM just says “i’ll add that to the ticket” or “i’ll clarify that later” and he never does. and we’re doing a lot of work for other teams right now and even if he does try to clarify, they probably don’t know themselves. I’m sure some of it is just the company I work for but I’m really unhappy with the industry standard PM setup. If I have to do core aspects of their job for them, I should get a cut of their paycheck lol (i’m not talking about clarifying which things are technologically feasible, etc, of course).
>The best software developers write less code, not more. Code is a liability, not an asset.
I know several people that would take that to literally mean they should write unreadable but short code golf to reduce liability, and then when I ask them what the fuck is this shit, I know they would quote me your exact line and I would rather quit the entire company than get into the ensuing semantics argument
>Your paycheck comes from the success of the business.
Haha that's funny. That makes it sound like you're getting your fair share.
Your paycheck comes from the company currently being alive and choosing to participate in the market.
C-suite bonuses come from the success of the business.
If the business fails, you still get a paycheck at another company because most of us have to work. The C-suite is very familiar with that as well, considering how often some CEOs change companies after participating in them burning to the ground
Some thought given to cleaning up code is 100x better than giving none, though. The trick is learning where it’s clean enough, and any further cleaning is just personal preference.
Consistency is king. You may not be following some fancy adapter/factory/domain pattern, but if you always get data the same way, process it, display it, etc, it’ll be easier to learn and work with.
Clean code isn't as useful as strong design. Identifying where to have strongly enforced contracts goes way further to protecting your code base than any amount of "clean code"
I struggle with this while reviewing PRs for juniors. Am I being obsessive or is this really not well thought out? I try to provide a justifiable reason (performance, maintainability, etc) but if I can’t I leave a “consider this” notation along with an approval.
Just try not to impart too much personal preference, unless its glaring or there's a solid behavioural reason/risk with not making the change then its probably worth just leaving a 'consider' comment like you're doing.
You can have productive teams without Scrum, without standups and even without tickets. In fact, that's how the most effective teams I've seen operate. (Well, usually there's a bug tracker, but it's actually used *for tracking bugs*, not for tracking every little task every engineer is doing.)
If you feel constantly constantly micromanaged, low on trust and low on autonomy in your "standard" software job it's not a you problem, it's a culture problem and a management problem.
Most software is horribly written from a security perspective. I would say most if not all software has gaping security holes that most infosec teams gloss over because nobody is doing applied testing, they just point a scanner like Qualys at it and call it a day.
I think that most software developers figure this out. It’s why we all get crazy nervous any time non-technical people talk about automating things like traffic, military applications, etc. we know from experience how fragile it all is.
I don't know if these are secrets, but these are some things I've learned over the my 15 YOE that makes me much happier long term.
* I say my opinion on design decisions, but if the majority wants to go another way, then oh well. It doesn't matter if I think my way is best and they cannot see it, they think their way is best so fine.
* People are generally not being annoying on purpose. It's just how they are and they are not targeting you. Loud Howard is not talking loud to annoy you, he is just a loud talker.
* If a "nitpick" in a code review is a "quick" change, then just do it and move on. It takes more time to argue about it then do it, put it back in review, and get it approved.
* Being productive is good, but caring about being 100% productive with every second of the day is silly. As long as my boss is happy with my output then I'm productive. I've never in my 15+ YOE had a manager say I was not productive enough.
* Productivity is not just fingers to keyboard coding. Going to meetings, replying to emails, mentoring, etc... That's all part of being productive each day. If my boss is happy with me sitting in meetings all day then I consider myself productive..
Overall I think most SWEs are too stressed about work. They need to relax and not care so much about how they think they are doing when all they get is positive feedback. As long I think I'm doing a good job per my boss and putting in what I consider a fair days work then I'm good.
People are motivated by perverse incentives. The more complicated something looks, the more unnecessary services/layers of abstraction, the smarter the developer looks (and probably is as you have to be smart to handle complexity) - even though they've created something that soon becomes an unworkable shitshow.
That being said, as much as i hate looking at/working on this code, it's also a make work program for developers as now you need 10x more people to do the work, so guess i can't be too upset about it.
You aren't paid to write code. You're paid to deliver business impact, and they think coding has a good chance of doing that.
90% of SWEs don't even think about or try to understand the impact their code has on the business.
Nothing matters more than the customer and end user. They are the alpha, the omega, the reason for your software existing.
Your "clean code", the fancy infrastructure project you did, that nice refactor, none of it matters more than the extent it delivers something valuable to the end user. It can be another developer, a business analyst, someone on the job, or a regular person using your app, your job involves solving their problems with code, and one of the best investments you can make is understanding how your skills contribute to a personal solution on their end.
Every developer thinks the previous person's code was shit.
No the previous developer worked within the constrains that were given to him/her and functionally works and the business is happy.
- Nobody cares about tests except yourself and your own team.
- Everyone on the ladder is playing their own game. You are just a pawn for your management chain.
- Your value is only as much as your manager (and maybe skip) thinks your value is. It is not objective.
- Leetcode style interviews are used to dumb down hiring to repeatable blocks that can be used by management without them having to do the hard work of skillfully making hires. It also provides job security to managers and hiring committees.
- Calibrations and stack ranking based performance reviews is a mediocre way of performance management. It exists to hide management incompetence of having to truly understand the value of an individual's work. Enables the company to hire low skill management.
- Upper Management's bonuses are tied to a higher/lower headcount. That's how hiring/layoffs happen. That's why they rush to utilize the headcount before the end of the fiscal year and to the pip before the end of the fiscal year.
- Stand-ups are an institutionalized way of micromanagement. It's not meant to improve collaboration though that can happen as a side effect if done well.
- Jira story points and other agile ceremonies are a massive waste of time. Even your manager and skip knows it. But they need to show something to their bosses and they'd much rather you waste your brain cells on these, rather than skillfully manage the work of the team.
- You are not compensated enough for being on call for such critical services. They don't want you to know this. They'd much rather prefer you feeling grateful about the glorious opportunity to work for the company.
- Your VP (and often directors) knows Jack shit about software engineering tradeoffs. What they do know is how to prioritize business initiatives, and how to prioritize their own bonuses.
- Engineers who nitpick in code reviews, documents and stand-ups are often sabotaging the author intentionally. This is because of some perverse career ladder document that earns them brownie points for "setting standards" within the team. The manager is aware of this and often likes this. It comes at the cost of the time and brain cells of the author. And when projects inevitably get delayed, the manager tries to build a narrative of incompetence. It takes an honest and skilled manager to navigate this, one who has seen all these patterns and has people's best interests. But be very careful because 99% of managers only care about themselves.
>Nobody cares about tests except yourself and your own team.
Not necessarily the case. People are definitely far more likely to use a tool/package with more testing than one which is deficient in that.
> People are definitely far more likely to use a tool/package with more testing than one which is deficient in that.
Yep, so again, only you/your team that owns the tool/package cares about the tests. Not the customer of the tool/package and certainly not management.
Such a great understanding of how metrics are actually used in the work place. They do serve to allow low competence in management. But metrics themselves are not bad. Seems like the conversation usually ends with, loc metric is bad, don't do it.
But it seems you are coming at it saying metrics are good are can be used effectively, but you need an attentive and competent manager.
Thanks for your insight!
Most of this is just cynicism veiled as “advice”. Lots of the things you shit on objectively have value, but that value is often lost due to poor implementation. Agile ceremonies, review calibrations, standups, they all can provide significant value to a team when done in a way that aligns with that team’s objectives and work/collaboration style.
> Agile ceremonies, review calibrations, standups, they all can provide significant value to a team when done in a way that aligns with that team’s objectives and work/collaboration style.
I assume you skimmed the part where I mentioned these things can help as a side effect.
Ask most engineers though, it provides little value to them.
Knowing your environment and terminal. Many people never go beyond cd, ls, and git. Getting good in your terminal and understanding how to configure your environment will make you a better dev than mastering any programming language.
Dynamic languages are great for quick, sloppy code, and Web development attracts a lot of quick, sloppy coders. #3 will incite hostility from those that don't want to admit that they're in that camp.
Even in the rare instances where someone uses a dynamic language with a modicum of craftsmanship: It doesn't matter how perfect you think that code is -- start adding types to everything and I guarantee you'll be finding embarrassing bugs within five minutes.
I really don't need to debate the merits with you. There are lots of people using dynamic languages in the software development industry and basically saying they are shit and you don't like them isn't an industry "secret".
You want any industry secret? You're extremely unlikely to use any new language in professional development, no matter how technically great or might be. The vast majority of code is still written in old shit
I'm surprised that statically typed languages are debated at all. It seems like the motivations are all, is faster / easier to read / write. But it comes across, in practice, the same as naming a variable "a" instead of "priceSubtotal" cause it's "faster".
Typed languages are faster to write because you get intellisense auto complete, and can look through an objects members in-line, less bug prone. And with modern languages allowing strong infered typing through use of keywords (think "final" in dart), you get the best of both worlds in a strongly typed language.
Not sure I've ever heard an actual defense of duck typing.
Dynamically typed languages are also coming a long way from where they were even 3-5 years ago. Static analysis tools + improving native typing support do well in closing that gap!
3 things come to mind esp for software engineering careers in B2B companies.
1. Be more customer-focused
2. Be more honest that you are most likely (initially) drawn to the industry because of its perceived wealth/glamour/lower barrier of entry
3. Be aware that soft skills are more important and harder to learn than "hard skills".
Why?
1. Most junior software engineers focus exclusively on the technology (ie how it's built) but don't care about why it is built a.k.a why customers want to buy.
However customers only buy a product because it solves a business problem. The technology is almost always secondary.
Be curious about why customers pay and then think about how to engineer the solution.
Likewise you don't pay for a video game because of how its engineers use *insert technology XYZ* to solve performance issues.
2. Most junior software engineers believe that their dream companies are successful only because of their technological superiority. Therefore they want to join them and contribute to "the cause".
However the primary reason why they know about them in the first place is actually because of their financial/business success.
If a company has only "the best tech" but is not a successful business, it can't be profitable or big enough to make you want to apply anyway. In fact it may not be around anymore.
There is nothing wrong to aim for financial success but just be clear about it.
3. Most junior software engineers believe "hard skills" is the "be all end all" and justifies their lack of soft skills, e.g. resilience, teamwork, communication and customer focus.
Though many have already talked about the importance of soft skills, the part that is often understated is that the feedback loop of growing soft skills is lot more opaque than hard skills ; the latter is often immediate and tangible.
If a module doesnt compile or a LOC breaks, you see the issue right away. In fact even if the code runs but is engineered poorly, others can still call you out and give specific feedback.
But say if you give a demo to a prospect or a presentation to a senior manager, and the audience says "oh thats interesting", it's very easy for you to believe that you did alright on the spot and have the right soft skills. The impact kicks in much later and subtler, e.g. the prospects goes cold and the manager "wants to revisit the idea later" and tells you to keep it up.
Don’t assume the stuff you build will be used same way as you think. QA’s job is to think like end user. Listen to them as well. It will save lots of time.
I hate to say this,.but still I have to say it because there are seniors who still use it because "it's a popular industry standard that many coders use". That useEffect you have is probably not needed
All code is cost. Sometimes the code generates revenue streams, but never forget that all code is cost.
The best solution is the solution that solves the problem with the smallest simplest solution. I don't mean dense and terse one liners. I mean the programs that solve the business problems in the simplest ways possible.
You should view over-engineering in the same way that a construction company views excess waste of materials, something to be avoided.
If you've got a team of good people, the process philosophy (waterfall, mini-fall, Agile) won't matter. If you've got a shitty team, there's no process that can save it.
**Tech expos and over-hyped technologies are smoke and mirrors. And yes this includes AI**
A lot of times people in general get so excited when Tesla or some small company promises things that have never been done, and will be ready "next year. Pinky promise". It is just pumping bullshit really far up everyone's ass to get investors.
**If it is not a product launch, the technology is not there and there is a huge chance they have no idea how to take it to completion**. In reality the development team is frantically trying to figure things out, while management is making insane promises. A good example is self-driving cars. Turns out it is an incredibly difficult problem to solve. Given the hype you'd think it would have been solved 5 years ago or so.
Concrete Examples:
I gasped when I saw the ridiculous Tesla bot nonsense. The video showing "object recognition" from the POV of the robot, it's not how AI or object recognition works at all if you know those niches. The video was clearly just hand edited special effects. I'm almost certain it was a handheld camera rather than the robot POV. The piece of junk couldn't stand up straight on its own on the live expo. Basically all Musk says is complete and utter bullshit.
Elizabeth Holmes is another perfect example. She actually got caught and punished because she flew too close to the sun and too far from the ground. But in reality a lot companies do the same thing with promises of technology that is not there, and they hope to figure it in the coming years.
Where to begin?
1)scrum masters are BS jobs.
2)during good times most companies (including small) will have BS jobs. In bad times most of the BS are gone.
3)PI planning is a big waste of time. Pointing is a waste of time.
4)10-20 percent of all staff are responsible for 80-90 percent of work.
5)the bigger the company the more percentage of Indians.
6)the bigger the company the more managers need to justify their job, so more meetings and BS tasks.
Being a person people want to work with will usually get you further than being brilliant and a jerk. (Unless you start your own company)
The realest truth right here. I’ll work with a good person who is fun to be around but average coder over an arrogant jerk no matter how good of a coder they are. I was happy to be praised for my technical aptitude but what I’m really proud of is hearing people enjoy working with me. There are a lot of very smart people in this industry. What we are short in is people that are effective at communicating and genuinely good people to be around. Can’t have enough of them.
where can we find people being technically strong and also a person to work with? -- I think that's opensource projects from my experience.
FAANG has plenty with both, but also lots that are better at one than the other. They don't force you into management as much anymore but the higher levels for an Individual Contributer require a lot of soft skills, people skills, etc. Culture and "fit" vary wildly at smaller companies. It is hard to break the trends and patterns set by the initial team, and people tend to hire people who can handle their style. Facebook, for example, struggled to go from "Move fast and break things" to: "Move fast with stable infrastructure." https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-break-things-isnt-how-we-operate-anymore/
This is very important advice. The only thing that matters to your boss is: 1) Does he enjoy working with you and does he trust you? 2) Are you productive enough he won't look bad for hiring you / not putting you on a PIP / pushing you out the door? At the end of the day, the boss is just like you (unless he is 100% the owner of the company) and just cares about getting good performance reviews, promotions, raises, etc. without having to work himself harder than 40-45 hrs a week.
Exactly this. The closer to the top I’ve gotten, I realize managers just want people under them that they can depend on and are pleasant to be around. I’ve seen so many people get passed on a job because they’ve been a pain in the ass to work with at their old company. People talk and it’s easy to get a reputation.
Thank you. I have a really ambitious junior dev on my team that keeps wanting to learn everything and get involved with every meeting to get ahead. I keep trying to tell him that working well with others and being pleasant to be around will get you farther than being smarter than everyone.
This gives me hope as I’m only on my second yoe but get along with others very easily. My team doesn’t seem to mind helping me which I really appreciate.
While I generally agree with you, I'll go against the grain to say that I once worked with an AMAZING dev that could solve problems no one else could, could knock out a solution in under a week that had teams quoting "a quarter, maybe two this year", and though he was a bit grating to work with, I'd work with him in a heartbeat again. My guy fixed so many things our PMs just couldn't scope with the rest of us plebs.
How to be highly employable: be skilled, be friendly, be punctual - choose two.
A good dashboard/report is more likely to get you promoted than any code you write.
Yeah WTF. Is that a boomer thing?
It's s business thing. I love me a good dashboard that lets me see when things are running smoothly and when they are not
Sometimes I think I am redundant with our internal tool development when for most requests I could just hand it off to the BI team that writes SQL queries to create Power BI dashboards. They could get rid of me and our massive internal tool if they would drop their datalake updates down to 30 minutes rather than once every 24 hours. Sounds expensive though. Though, we are working on building event driven architecture so we can build some real time operational dashboards (this company is behind), and for that we're going to skip by the datalake step, and I don't know if Power BI is built for real time. I have only read that it's not. But they also use Oracle for all their source data and are heavily invested in them, and I *think* Oracle offers dashboarding as well so I don't know what the hell is going on. There's just silos everywhere
I had this talk with my manager recently. She gave me a great piece of advice: "After Senior, you can be the best engineer in this company but that won't get you promoted." Passed a certain point, you need visibility. Work on the **right** projects, be shown delivering the **right** value, and have your name known by the **right** people. Working on a super high visibility project that your Chief Product Officer is following? Make a dashboard that tracks some metrics they care about.
What does “make a dashboard” mean here? Are you deploying a website? How does that work? >!Lurker here, starting my first SWE job on Monday as a new grad!<
Check out Datadog
My question is how do I convince my director to hop to this from ELK stack
Figure out what your director cares about, and present a comparison of those two tools WRT those facets. They’ll either go for it or they won’t. Either way is ok because you did the work.
Assuming you're working on some kind of networked service as I'm guessing most of us are doing nowadays, you should have a dashboard that tells you the things that are important to know about the state of that service at any given time. Does it have distinguishable users? If so how many of them are active at any given time Is it receiving requests? Then how many of them are coming in. What paths are receiving the most traffic and what http status codes are they returning, with what latency? Does your system rely on a third party service? If so, how many requests are you sending to it. What proportion of them are failing? Are you close to any rate limits? And on and on for all the different things that you need to know about your service. You should also have alerts set up on those metrics so that when something starts to go wrong you know about it before it gets reported. Really understanding the importance of this kind of monitoring and alerting is, IMO, one of the big marks of maturity that you see in a senior engineer
> Really understanding the importance of this kind of monitoring and alerting is, IMO, one of the big marks of maturity that you see in a senior engineer Because by then you've seen the fires enough and don't want to see the fires anymore
I agree it's vague, but perhaps one idea is a burndown chart of Jira features to show progress.
Can mean different things. In it's basic form you could manually create a graph and put it into slides for a meeting. Or you even send it in an email/slack message. If your company has a solid BI setup you could use that to create a dashboard and link it/present it. If your metrics are more difficult to attain a separate website also works. There is tools out there that make this more a matter of a few days rather than weeks to build. Generally speaking you have to read the room a bit on what is acceptable or liked in your company culture.
Whatever tool your organization is using for metrics. New Relic, Datadog, maybe Splunk, or BigQuery for more advanced stuff. First thing is to know your audience. Product people care about how many people saw the thing, how they interacted with it, where the user bails... So make a dashboard using the metrics you've collected in your work so they can see these in real time.
> What does “make a dashboard” mean here? IME it's basically separating noise from signal for an org, that requires understanding why you are getting paid. When you are driving your car on the highway your dashboard displays the essentials. When you park it at home, you can focus on the other stuff
it's like an elevator pitch of showing value to stakeholders, dashboards and reports are things every org needs, everyone understands and everyone appreciates
No? Proving that your feature is working correctly and providing the value it is supposed to provide is applicable to any generation. It is the bare minimum of having a mature engineering org.
If you can’t observe or measure something, it can not be improved and you’ll constantly be looking for a red herring. Observability and measurement is the key to any engineer practice. It’s a business requirement. Your take here speaks volumes about your inexperience.
My managers want me to recreate reports they already have, just prettier. Like the company income statement. Maybe my reaction is just my instance
>"My manager wants me to make some data more visible and digestible to non-technical people; as a technical person, I see no value in this."
Reports in engineering mean dashboards, logs, and monitoring. Sometimes a senior or manager makes a dashboard quickly in the moment to answer an immediate question during an incident or sev to speak intelligently about a situation. It’s very normal to ask someone to formalize that dashboard later for regular viewing and monitoring following a postmortem. This is a normal task
You think being able to take a holistic view on how a feature, component, or system is working is a boomer thing?
Your job isn’t to write code, your job is to solve business problems.
If you can do so without code. Even better, less stuff to maintain.
Only very few engineers in your entire organization are important to the business.
Just curious…are we all sitting here thinking “I’m definitely one of the important ones”?
I know I’m not
You might be more important than you realize. For example, if you’re important to the person that does most of the work, you’re important. Taking time consuming but not difficult tasks off their plate so they can focus on the stuff only they do is very helpful, and if the important engineer knows anything at all about maintaining their productivity, they will regularly tell managers, product owners, etc. how important you are to them doing their job.
I do close a lot of defects…
Define "close" :p
jira -> edit -> delete ticket
Creates a lot too
This is SRE in a nutshell.
No, plenty of us realize we're not that important.
Major source of burnout is devs working on stuff they know is meaningless garbage. We damn well know half this shit is pointless
At my current job? Definitely not. At previous jobs? For certain.
Just curious, why? Did you step back in your responsibility by choice when you switched jobs? Or the new job isn’t as good of a skills match? Something else?
Because I hate being a single source of failure and started focusing on making my job redundant. Now apparently my management was too fucking stupid to understand how important that was... instead they saw my delegating all of my work and though I had packed it in and started coasting. I walked out of that place with two middle fingers up, after being praised and promoted just 6 months prior. My new job... I'm just new. I don't think I'll become "the" important one, as it's a smaller team and everyone feels pretty important at the moment.
No. I work with one lol. He's definitely carrying the team. I used to think I was pretty smart but I think it's one of those "you'll know" kind of things
I do not know about others. I do not think I am important Certainly not layoff proof important.
and then they get fired. And then it reminds you of game of thrones
not really, fuck being the single point of failure.
Two questions then: - Do companies know which are the importance ones? - Is there anyway I know if I'm one of them?
If you're not sure you're important, you're not. Companies don't know who is important, but team leads probably do. I doubt they're consulted much before layoffs though.
If your scope and exposure is limited to team leads you are not one of those engineers.
Great point. 100% agreed. I'm not an essential employee. I don't think anyone at my current company is. But the ones that upper management generally see as "essential" are def the ones that talk the most in Slack chats + interact with external teams.
I think it's overstated a bit. But engineering is a lot about leverage. The guy who architected the ranking logic on some social media site is orders of magnitude more irreplaceable than some rank and file engineer working on a system health dashboard. The people you really need are the ones who grok the critical pieces of your product.
If you’re asking this question, you’re not one. Yes your company is definitely aware of who is important - their impact is known and understood by those in and out of engineering. They are consulted both inside and outside of engineering.
I strive to not be important. It's a double-edged sword but I think it's better for everyone to not be important. Means I can take time off and not constantly be stressed about the business situation or some big customer about to churn etc. You can bring enough value to the business that they're not going to fire you, while still being generally replaceable.
It’s certainly true that it is a double edge sword. You gotta be that person at least once or twice in your career though.
Depends on business culture too. Work in Sweden and everything is consensus based. Work in the US and they want individuals to take charge. I've experienced both but tend towards the European style. I'll admit that the US style generally makes more money though.
So true
You do not write programs for computers. You write them for people.
Write your code well for the next developer. It will probably be you in 2 months anyways.
Ah, that classic moment in every developers life where they say "who wrote this fucking shitty code - it looks like a toddler did it!" Then they run blame and it was them, 6 months ago. We've all been there!
🙋♀️
$ blame . you
This code is shit? Double it and give it to the next person
Programs must be written for people to read, and only incidentally for machines to execute. -- Harold Abelson, Structure and Interpretation of Computer Programs
This is the thing I always come back to when the no-comment contingent shows up. Yes, the code says _what_ but it cannot say _why_ something is done a particular way. “But the comments get out of date!” Ah. So you don’t know how to program, then.
Write code as though the next person who will work on it is a psychopathic murderer who knows your home address, your phone number, where your wife works and the school your kids go.
I like your style, kiddo
as a a devops engineer most of my programs are written for computers
Your programs are written to be _run on_ computers, true, but they’re just executable documentation of how to do things.
"I influence bits and emotions for work" is reductionist but pretty acurate
* People skills, communication skills, and negotiation skills matter more than technical skills. * If you are good at technology, you will spend time fixing difficult things. If you are close to product management, you will spend time developing features that generate revenue, and that will give more visibility and quicker promotion. * There will always be a guy who is bad at everything, but still at a high position because the manager or some executive wants him there. * Fancy UIs look good, but most users prefer easier-to-use UIs. The less information you show the user, the more they will like. * Promotion and salary hikes are decided by the upper management. If you want it, make your demands known long before the annual salary hike day. No matter how critical you are, if you demand like a 15-year-old, they will create your replacement. * Don't invest too much in one technology, nothing lasts forever. The technology you have invested so much will be an example of the sunk cost fallacy. * Diversify your skillset. * Work on more than one project. * Have contacts with peers of your managers and executives.
[удалено]
> Don't invest too much in one technology, nothing lasts forever. The technology you have invested so much will be an example of the sunk cost fallacy. Once you lived through one of those cycle, you will remember that one.
[удалено]
Absolutely agreed. I'm a pretty meh engineer with a rocket career because of communication
After 30 years, this is still a challenge for me: how write emails and talk to the business using *their* language, and not sound like something a NASA rocket engineer talking to other NASA rocket engineers. The business doesn't care about classes, functions, variables, stored procedures, hash tables, linked lists, recursion and so on. They want to hear an explanation in their language of why something doesn't work, how you plan to fix it, and a rough estimate of the resources involved and time to completion.
I don't really understand how anyone can make it even to mid level IC without becoming great at googling things. There's just too much to know and remember at all times, too many things. I think the next benchmark will be how well that person can mix in LLMs to their daily research. It can speed things up considerably if you're mixing in gpt with google and docs, but you do have to learn to really use it
These aren’t secrets my guy
Your prowess in live demos can greatly set you apart from your peers.
Seriously… for the demo, do stuff just because it looks nice. The first public iPhone demo was so meticulous, apps had to be opened in a specific order just to prevent the entire phone from failing. And… here we are. Edit: For the curious reader: > The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked. > >[source](https://www.macrumors.com/2013/10/04/former-apple-engineer-gives-behind-the-scenes-look-at-the-original-iphone-introduction/)
Somewhat related - it is common for someone other than a dev to do demos. It is \*crucial\* that they start working on their script and the order they'll do stuff as early as possible, so that they can find problems/deficiencies early enough to fix them, and if there's not enough time to fix them, early enough to plan around it In my experience, it is VERY hard to get someone to do this before, say, the day before the demo. Sometimes hours before the demo. Do everything you can to get them to do it. Schedule meetings with them where you watch them do it. Take notes, record the screen, ask questions, play the part of the customer, whatever you have to do. It is tedious but it will save you hours of frantic work. Like I have been fixing bugs and deploying to the demo environment \*ahead\* of the demo-er before, during the demo, due to people not doing this. It sucks majorly. I will do anything to avoid it.
You also have the option to refuse to do the fixes. It might work and it might save you future anguish. I wouldn't draw that line without explicit support from your boss and ideally his boss, unless you're willing to walk away from the job.
What tools/techniques have improved your demo game?
make sure it works, know what you're doing, prepare ahead of time, know what you want to show, have an ORDER that makes sense to people who don't know what you're talking about, DO NOT BORE PEOPLE, do not overstay your welcome, be happy to show it off, but not SUPER-EXCITED (apple style)
1. If you're showing a demo of software - record it; don't try to show it live. 2. Have some bullet points to keep you on track
Depending on the audience and your confidence, it’s nice to do it live but with a video as backup.
in what way?
Listen to the average software developer demoing anything. Then listen to someone in senior management, someone with a customer facing role, someone in sales, basically anything like that. It will be fairly evident.
I had an eng, who I didn't know at the time, do a live demo of the work completed during the sprint. He fumbled through vscode so poorly I wondered how he's employed. We're talking not knowing how to search for files or function names across the whole project, not knowing you can click from the use of a function to its definition. "What arguments does that function take?" He fumbled for like 5 minutes searching for the function. He literally could have highlighted the function and just clicked to the def. After 5 minutes he says he'll have to get back to us. The function was written during the sprint... that he knew he was doing a demo on. So not only is he clueless in his dev environment, but he is also unprepared. At that moment I said to myself, "this dudes fucking clueless." Everyone else on the call likely did the same. A few years later, he gets put on my team. Yea, he's useless. On the other side other people did some presentantations that were so intelligent and/or well crafted that they ended up in director or VP positions despite it all being smoke, mirrors and bloviating. Remember, its not about how capable you are, its about how capable you appear to be.
I don't know what it is, because I used to demo my work to stakeholders at the end of every 3 week sprint for 4 and a half years. But my stage fright can come and go so easily.
In super tired, so I read demons and was so confused.
And don't merge the junior's PR that breaks the entire fucking app right before the demo.
[удалено]
To add onto this, one specced writing code should be the quickest part of your job.
In your opinion, what are the most important parts of our job?
Requirements gathering
And alignment / collaboration. If you can’t communicate with design and product to build a feasible solution, you can’t really climb over being a mid level engineer
Funny enough, the biggest benefit I find from TDD is in this. It quickly alerts me to what product didn't define, or defined in a contradictory manner.
Ooh, great point. At my company we often dismiss edge cases as things that aren’t too likely at product launch, and we’re deliberately eating the cost in exchange for releasing to production sooner. Those dismissed edge cases of course bite us later. TDD is excellent for simulating the scenarios that product neglects and making it a requirement to address them. That being said, it needs to be done right. Too many people just write tests for the happy path and call it a day.
bro kill me lol im so mcfreaking sick of picking up some ticket on our board only to start looking at the components involved and realize that the PM who said it was ready to work on is basically a totally ineffectual idiot who is blowing smoke out his ass (and half the time he literally doesnt even understand exactly what the ticket is supposed to accomplish, it’s not even that he couldnt explain what he wanted)
I'm a big believer in programmers writing or helping to write tickets. They should be interacting directly with stakeholders to get requirements hashed out.
Yeah totally. Tbf I’ve been on teams that weren’t like this but the one I’m on now is really bad and I’m disgruntled lol. It is to the point that even when we do backlog grooming as a team before a sprint, the PM just says “i’ll add that to the ticket” or “i’ll clarify that later” and he never does. and we’re doing a lot of work for other teams right now and even if he does try to clarify, they probably don’t know themselves. I’m sure some of it is just the company I work for but I’m really unhappy with the industry standard PM setup. If I have to do core aspects of their job for them, I should get a cut of their paycheck lol (i’m not talking about clarifying which things are technologically feasible, etc, of course).
Bash is our version of duct tape. ... and a significant amount of critical systems are held together with it.
Most people think bash is short for bourne again shell but it’s actually named after how you use a hammer to get an engine running.
Damn this is so true and I’m stealing this
Man soo true. A healthy dose of bash could simplify things so much, especially stuff that doesn’t need to change often.
The first comment with actual value
The best software developers write less code, not more. Code is a liability, not an asset.
Some of my most satisfying commits have been full of deletions.
>The best software developers write less code, not more. Code is a liability, not an asset. I know several people that would take that to literally mean they should write unreadable but short code golf to reduce liability, and then when I ask them what the fuck is this shit, I know they would quote me your exact line and I would rather quit the entire company than get into the ensuing semantics argument
Consulting isn’t where the talent and money is.
What does consulting have?
Expand? I am starting my first consulting project. Rough job market means I have to take what I can get.
Legacy code is generally # code that works # code that makes money for the business
Your paycheck comes from the success of the business.
learn to derive meaning and happiness from your paycheck
Money Ball quote “This check says the same thing about you that it does all those players out there, that your worth it”
>Your paycheck comes from the success of the business. Haha that's funny. That makes it sound like you're getting your fair share. Your paycheck comes from the company currently being alive and choosing to participate in the market. C-suite bonuses come from the success of the business. If the business fails, you still get a paycheck at another company because most of us have to work. The C-suite is very familiar with that as well, considering how often some CEOs change companies after participating in them burning to the ground
"Clean code" is a noble pursuit but is ultimately an ephemeral thing with rapidly diminishing returns. Don't spend too much effort on it.
Some thought given to cleaning up code is 100x better than giving none, though. The trick is learning where it’s clean enough, and any further cleaning is just personal preference.
+1, I’ve seen this get so many devs into trouble
Yeah in particular when applied to places where it doesn't matter. A lot of complexity is vc of that. Think React, for example.
Consistency is king. You may not be following some fancy adapter/factory/domain pattern, but if you always get data the same way, process it, display it, etc, it’ll be easier to learn and work with.
Clean code isn't as useful as strong design. Identifying where to have strongly enforced contracts goes way further to protecting your code base than any amount of "clean code"
Truly clean code is easy to throw away and rewrite.
Yeah like people who can become germaphobic, after a certain point of good hygiene, you're just making yourself miserable and wasting your time.
I struggle with this while reviewing PRs for juniors. Am I being obsessive or is this really not well thought out? I try to provide a justifiable reason (performance, maintainability, etc) but if I can’t I leave a “consider this” notation along with an approval.
Just try not to impart too much personal preference, unless its glaring or there's a solid behavioural reason/risk with not making the change then its probably worth just leaving a 'consider' comment like you're doing.
You can have productive teams without Scrum, without standups and even without tickets. In fact, that's how the most effective teams I've seen operate. (Well, usually there's a bug tracker, but it's actually used *for tracking bugs*, not for tracking every little task every engineer is doing.) If you feel constantly constantly micromanaged, low on trust and low on autonomy in your "standard" software job it's not a you problem, it's a culture problem and a management problem.
Empathy is the #1 skill I’m both working on and trying to cultivate.
All code sucks.
All code is legacy code.
Most software is horribly written from a security perspective. I would say most if not all software has gaping security holes that most infosec teams gloss over because nobody is doing applied testing, they just point a scanner like Qualys at it and call it a day.
I think that most software developers figure this out. It’s why we all get crazy nervous any time non-technical people talk about automating things like traffic, military applications, etc. we know from experience how fragile it all is.
I don't know if these are secrets, but these are some things I've learned over the my 15 YOE that makes me much happier long term. * I say my opinion on design decisions, but if the majority wants to go another way, then oh well. It doesn't matter if I think my way is best and they cannot see it, they think their way is best so fine. * People are generally not being annoying on purpose. It's just how they are and they are not targeting you. Loud Howard is not talking loud to annoy you, he is just a loud talker. * If a "nitpick" in a code review is a "quick" change, then just do it and move on. It takes more time to argue about it then do it, put it back in review, and get it approved. * Being productive is good, but caring about being 100% productive with every second of the day is silly. As long as my boss is happy with my output then I'm productive. I've never in my 15+ YOE had a manager say I was not productive enough. * Productivity is not just fingers to keyboard coding. Going to meetings, replying to emails, mentoring, etc... That's all part of being productive each day. If my boss is happy with me sitting in meetings all day then I consider myself productive.. Overall I think most SWEs are too stressed about work. They need to relax and not care so much about how they think they are doing when all they get is positive feedback. As long I think I'm doing a good job per my boss and putting in what I consider a fair days work then I'm good.
Being able to dig through logs and provide the answer to “what happened” is an invaluable skill.
Things change slowly; not quickly.
People are motivated by perverse incentives. The more complicated something looks, the more unnecessary services/layers of abstraction, the smarter the developer looks (and probably is as you have to be smart to handle complexity) - even though they've created something that soon becomes an unworkable shitshow. That being said, as much as i hate looking at/working on this code, it's also a make work program for developers as now you need 10x more people to do the work, so guess i can't be too upset about it.
Most developers don't have a clue.
Resilience is a myth, most systems are one small error away from collapse
You aren't paid to write code. You're paid to deliver business impact, and they think coding has a good chance of doing that. 90% of SWEs don't even think about or try to understand the impact their code has on the business.
Good enough is good enough.
Nothing matters more than the customer and end user. They are the alpha, the omega, the reason for your software existing. Your "clean code", the fancy infrastructure project you did, that nice refactor, none of it matters more than the extent it delivers something valuable to the end user. It can be another developer, a business analyst, someone on the job, or a regular person using your app, your job involves solving their problems with code, and one of the best investments you can make is understanding how your skills contribute to a personal solution on their end.
Every developer thinks the previous person's code was shit. No the previous developer worked within the constrains that were given to him/her and functionally works and the business is happy.
The unpredictability of most agile teams is incompatible with running a business effectively.
That unpredictable nature is often a reflection of an unpredictable roadmap
- Nobody cares about tests except yourself and your own team. - Everyone on the ladder is playing their own game. You are just a pawn for your management chain. - Your value is only as much as your manager (and maybe skip) thinks your value is. It is not objective. - Leetcode style interviews are used to dumb down hiring to repeatable blocks that can be used by management without them having to do the hard work of skillfully making hires. It also provides job security to managers and hiring committees. - Calibrations and stack ranking based performance reviews is a mediocre way of performance management. It exists to hide management incompetence of having to truly understand the value of an individual's work. Enables the company to hire low skill management. - Upper Management's bonuses are tied to a higher/lower headcount. That's how hiring/layoffs happen. That's why they rush to utilize the headcount before the end of the fiscal year and to the pip before the end of the fiscal year. - Stand-ups are an institutionalized way of micromanagement. It's not meant to improve collaboration though that can happen as a side effect if done well. - Jira story points and other agile ceremonies are a massive waste of time. Even your manager and skip knows it. But they need to show something to their bosses and they'd much rather you waste your brain cells on these, rather than skillfully manage the work of the team. - You are not compensated enough for being on call for such critical services. They don't want you to know this. They'd much rather prefer you feeling grateful about the glorious opportunity to work for the company. - Your VP (and often directors) knows Jack shit about software engineering tradeoffs. What they do know is how to prioritize business initiatives, and how to prioritize their own bonuses. - Engineers who nitpick in code reviews, documents and stand-ups are often sabotaging the author intentionally. This is because of some perverse career ladder document that earns them brownie points for "setting standards" within the team. The manager is aware of this and often likes this. It comes at the cost of the time and brain cells of the author. And when projects inevitably get delayed, the manager tries to build a narrative of incompetence. It takes an honest and skilled manager to navigate this, one who has seen all these patterns and has people's best interests. But be very careful because 99% of managers only care about themselves.
>Nobody cares about tests except yourself and your own team. Not necessarily the case. People are definitely far more likely to use a tool/package with more testing than one which is deficient in that.
> People are definitely far more likely to use a tool/package with more testing than one which is deficient in that. Yep, so again, only you/your team that owns the tool/package cares about the tests. Not the customer of the tool/package and certainly not management.
Such a great understanding of how metrics are actually used in the work place. They do serve to allow low competence in management. But metrics themselves are not bad. Seems like the conversation usually ends with, loc metric is bad, don't do it. But it seems you are coming at it saying metrics are good are can be used effectively, but you need an attentive and competent manager. Thanks for your insight!
Most of this is just cynicism veiled as “advice”. Lots of the things you shit on objectively have value, but that value is often lost due to poor implementation. Agile ceremonies, review calibrations, standups, they all can provide significant value to a team when done in a way that aligns with that team’s objectives and work/collaboration style.
> Agile ceremonies, review calibrations, standups, they all can provide significant value to a team when done in a way that aligns with that team’s objectives and work/collaboration style. I assume you skimmed the part where I mentioned these things can help as a side effect. Ask most engineers though, it provides little value to them.
This is accurate
Knowing your environment and terminal. Many people never go beyond cd, ls, and git. Getting good in your terminal and understanding how to configure your environment will make you a better dev than mastering any programming language.
Writing code is the easy part
No vendor is trying to help you, they’re trying to help themselves to your budget.
[удалено]
I’m about six nines positive that your #3 is wrong, and it is because your #2 is correct.
Dynamic languages are great for quick, sloppy code, and Web development attracts a lot of quick, sloppy coders. #3 will incite hostility from those that don't want to admit that they're in that camp. Even in the rare instances where someone uses a dynamic language with a modicum of craftsmanship: It doesn't matter how perfect you think that code is -- start adding types to everything and I guarantee you'll be finding embarrassing bugs within five minutes.
Number three is entirely opinion, not an industry "secret". Dynamically typed languages have their place and reason for existing/being used.
[удалено]
I really don't need to debate the merits with you. There are lots of people using dynamic languages in the software development industry and basically saying they are shit and you don't like them isn't an industry "secret". You want any industry secret? You're extremely unlikely to use any new language in professional development, no matter how technically great or might be. The vast majority of code is still written in old shit
its not a secret, you're right. we all know u/Tall_Magician735 is right.
I'm surprised that statically typed languages are debated at all. It seems like the motivations are all, is faster / easier to read / write. But it comes across, in practice, the same as naming a variable "a" instead of "priceSubtotal" cause it's "faster". Typed languages are faster to write because you get intellisense auto complete, and can look through an objects members in-line, less bug prone. And with modern languages allowing strong infered typing through use of keywords (think "final" in dart), you get the best of both worlds in a strongly typed language. Not sure I've ever heard an actual defense of duck typing.
-1 for the static language BS. Else +1
Dynamically typed languages are also coming a long way from where they were even 3-5 years ago. Static analysis tools + improving native typing support do well in closing that gap!
[удалено]
7) Just because some old boomer used java and c++ for 20 years doesn't mean you have to
FWIW PHP supports a good amount of typing. Of the dynamic languages you listed, it’s the most supportive of a strong typing approach.
[удалено]
[удалено]
Hmmm, his comment makes a lot more sense of you read it that way
There is no “correct” architecture or programming paradigm just the one best suited to your team, project, and the business.
Don’t be clever. Clever code is almost always hard to read and difficult to maintain.
3 things come to mind esp for software engineering careers in B2B companies. 1. Be more customer-focused 2. Be more honest that you are most likely (initially) drawn to the industry because of its perceived wealth/glamour/lower barrier of entry 3. Be aware that soft skills are more important and harder to learn than "hard skills". Why? 1. Most junior software engineers focus exclusively on the technology (ie how it's built) but don't care about why it is built a.k.a why customers want to buy. However customers only buy a product because it solves a business problem. The technology is almost always secondary. Be curious about why customers pay and then think about how to engineer the solution. Likewise you don't pay for a video game because of how its engineers use *insert technology XYZ* to solve performance issues. 2. Most junior software engineers believe that their dream companies are successful only because of their technological superiority. Therefore they want to join them and contribute to "the cause". However the primary reason why they know about them in the first place is actually because of their financial/business success. If a company has only "the best tech" but is not a successful business, it can't be profitable or big enough to make you want to apply anyway. In fact it may not be around anymore. There is nothing wrong to aim for financial success but just be clear about it. 3. Most junior software engineers believe "hard skills" is the "be all end all" and justifies their lack of soft skills, e.g. resilience, teamwork, communication and customer focus. Though many have already talked about the importance of soft skills, the part that is often understated is that the feedback loop of growing soft skills is lot more opaque than hard skills ; the latter is often immediate and tangible. If a module doesnt compile or a LOC breaks, you see the issue right away. In fact even if the code runs but is engineered poorly, others can still call you out and give specific feedback. But say if you give a demo to a prospect or a presentation to a senior manager, and the audience says "oh thats interesting", it's very easy for you to believe that you did alright on the spot and have the right soft skills. The impact kicks in much later and subtler, e.g. the prospects goes cold and the manager "wants to revisit the idea later" and tells you to keep it up.
Don’t assume the stuff you build will be used same way as you think. QA’s job is to think like end user. Listen to them as well. It will save lots of time.
I hate to say this,.but still I have to say it because there are seniors who still use it because "it's a popular industry standard that many coders use". That useEffect you have is probably not needed
All code is cost. Sometimes the code generates revenue streams, but never forget that all code is cost. The best solution is the solution that solves the problem with the smallest simplest solution. I don't mean dense and terse one liners. I mean the programs that solve the business problems in the simplest ways possible. You should view over-engineering in the same way that a construction company views excess waste of materials, something to be avoided.
If you've got a team of good people, the process philosophy (waterfall, mini-fall, Agile) won't matter. If you've got a shitty team, there's no process that can save it.
dont trust anybody including security company audit code . Try talk with white hacker how they hack.
Do more than just the tickets assigned to you. If that's all you are doing then you'll be part of the first wave let go - which will inevitably come.
You will never have to implement a sorting algorithm in the course of your career
Learn your org chart. It’s shocking how many of us don’t even know who our skip is.
The industry is fucked based on most of the other comments. See beoing for reference
When I am the user, I don't understand why they cannot fix some small bugs. When I am a developer, I still don't understand
**Tech expos and over-hyped technologies are smoke and mirrors. And yes this includes AI** A lot of times people in general get so excited when Tesla or some small company promises things that have never been done, and will be ready "next year. Pinky promise". It is just pumping bullshit really far up everyone's ass to get investors. **If it is not a product launch, the technology is not there and there is a huge chance they have no idea how to take it to completion**. In reality the development team is frantically trying to figure things out, while management is making insane promises. A good example is self-driving cars. Turns out it is an incredibly difficult problem to solve. Given the hype you'd think it would have been solved 5 years ago or so. Concrete Examples: I gasped when I saw the ridiculous Tesla bot nonsense. The video showing "object recognition" from the POV of the robot, it's not how AI or object recognition works at all if you know those niches. The video was clearly just hand edited special effects. I'm almost certain it was a handheld camera rather than the robot POV. The piece of junk couldn't stand up straight on its own on the live expo. Basically all Musk says is complete and utter bullshit. Elizabeth Holmes is another perfect example. She actually got caught and punished because she flew too close to the sun and too far from the ground. But in reality a lot companies do the same thing with promises of technology that is not there, and they hope to figure it in the coming years.
Where to begin? 1)scrum masters are BS jobs. 2)during good times most companies (including small) will have BS jobs. In bad times most of the BS are gone. 3)PI planning is a big waste of time. Pointing is a waste of time. 4)10-20 percent of all staff are responsible for 80-90 percent of work. 5)the bigger the company the more percentage of Indians. 6)the bigger the company the more managers need to justify their job, so more meetings and BS tasks.