Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

101–110 of 339 posts

Re: What Silicon Valley gets about engineers that traditional companies do not

#101

It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom. But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly…

I feel like the article is mostly written from a product perspective. I worked in an area that was billed out by the hour, it was just complicated enough to require developers to do the work, but the work pieces were very quantifiable (add text to say xyz based on a business rule, show different images based on a rule, etc). It meant graduate programmers, immigrants with limited English skills, or others without much talent or drive would end up there. It's a good safe role for someone who just wants to get paid and go home on time (usually).

It was very much a factory in the way the article says, but I feel like it has to be because of the nature of the work. I did talk to customers directly on larger projects but since I was building on top of internal systems and processes my role was mainly implementation/glue coding. Most of my frustrations were with our internal dev and IT who built and maintained the systems - over time they became more walled off, not less, which definitely impacted our work. And unfortunately as we were more 'client facing' any outages came back to bite us, not them, which was an annoying organisational dysfunction. They simply weren't incentivised to care as much as we were.

Re: What Silicon Valley gets about engineers that traditional companies do not

#102
post #33

The best way to tell if a company values engineers is to ask which cost center they are in. Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

I made the switch you are talking about. I did talk about my job in the interviews, and in retrospect that would have been a pretty clear signal than I didn't know how that type of company works. I think I got the job because my employer is primarily looking for competent problem solvers, and they are willing to teach the rest on the job. Not all companies may be like this, but the big ones probably will.

Re: What Silicon Valley gets about engineers that traditional companies do not

#103
post #24

Earlier quoted context omitted.

Yes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers. The ironic thing about Agile is that it has a cottage industry of "scrum c…

I've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.

[deleted]

Re: What Silicon Valley gets about engineers that traditional companies do not

#104
post #73

Earlier quoted context omitted.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

I haven't done it myself, but I've hired people who were stuck in IT. Just don't talk negatively about your old job. "I'm looking to move because I want to have more impact". "The work I'm doing now is not core to company's success and I want to have more impact". Etc. I never looked down on someone who was doing boring work if that is what they were supposed to be doing. I'm looking for people who can communicate we…

I guess I’m worried about talking about how we have really poor development practices. It’s hard to describe what I do, they try to block people from learning about what their kanban card is for. I just write proprietary scripting language functions then fill out a Word document “unit test” about them. I guess I can editorialize and try to steer the conversation towards what I can bring to the company. Thanks for the advice!

Re: What Silicon Valley gets about engineers that traditional companies do not

#105
This article hit me hard. I work in a non Silicon Valley-like company. I became a developer because I thought I love coding. But I found out that, in fact, I love problem solving. Tightly defined Scrum tasks make me sad and I would love to have more autonomy.

Re: What Silicon Valley gets about engineers that traditional companies do not

#106

Earlier quoted context omitted.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

I made the switch you are talking about. I did talk about my job in the interviews, and in retrospect that would have been a pretty clear signal than I didn't know how that type of company works. I think I got the job because my employer is primarily looking for competent problem solvers, and they are willing to teach the rest on the job. Not all companies may be like this, but the big ones probably will.

That’s good to know, thanks. Congrats on the move!

Re: What Silicon Valley gets about engineers that traditional companies do not

#107
post #45

From personal experience on the product side, if you want to be more involved with the business, I'd recommend you work on two things from this article. First, curiosity is an absolutely must have. Without it, you'll not be able to truly learn what a customer is looking for. Second, demonstrate you can "talk with another engineer" without manager facilitation. It's a signal of ownership that I guarantee people will n…

I've done both of these my entire career and no one ever cared, mostly because it's not remarkable. Do you work somewhere that has a large management apparatus? These behaviors are sort of bare minimum expectation in smaller companies. It sounds like you perceived developers as a group to be mostly anti-social curmudgeons.

I've worked in large and small, with good and bad cultures. And to be clear, that is not my view of developers. I point it out because I agree with the author of the article that there are differences in companies. I'm sorry that those traits did not get you where you wanted, but they are not bare minimum in a lot of companies. I've walked engineers from their seats over to the counterpart's seat and have had others who do not go outside of their area due to an inaccurate belief that it's not what their manager wanted.

Re: What Silicon Valley gets about engineers that traditional companies do not

#108
This article...exaggerates...the difference between SV and 'not SV' companies. A lot, actually. I've worked at a few places in SV, and several outside of SV, too. For the most part it's similar: use the existing infrastructure and implement a service, front-end, whatever, within that, to solve a business need. Very little in the way of novel or new solutions to genuinely new problems is required. The difference is mainly in pay and, to a much lesser degree, respect.

Regarding autonomy--usually a high degree of autonomy is found in two places: 1) at larger companies, a very senior, trusted individual who has proven himself to be competent and capable of making big decisions; 2) at startups, a very junior individual scratching an itch and loading up on technical debt.

For the most part solutions are prescribed or narrowly constrained--99.999% of engineers are going to use the same services architecture, libraries, and compute infra every other engineer is using.

Regarding curiosity and problem solving: I guess I have a different definition of "curiosity" and "problem solving." What I've seen in this industry ain't either, generally: it's mainly driven by personalities at the individual or corporate level, e.g., "everyone" doing what Google does or following Fowler, and empirically unsupported anecdotes/fads (e.g. TDD, agile, etc.). The vast majority of engineering work in any established company is to use an existing tool or infra to implement a generally well-defined need. Most of the interesting details are already solved, and the implementation work, while also interesting, isn't really solving the problem, per se.

Re: What Silicon Valley gets about engineers that traditional companies do not

#109

The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong. I have worked at a good number of places, including a FAAMG. The freedom that was given to me directly correlates to company size & seniority. When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems…

Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.

not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch...

What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems.

But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases

Re: What Silicon Valley gets about engineers that traditional companies do not

#110

The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong. I have worked at a good number of places, including a FAAMG. The freedom that was given to me directly correlates to company size & seniority. When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems…

> JIRA is a touchstone that seems to equate to no autonomy

Jira doesn't intrinsically take away engineers' autonomy but in many cases it's the most visible manifestation of company policies/procedures that do.

Post reply on HN