One of the things I have noticed lately is that people who change jobs often have completely different perception of the industry as compared to people who don't change that often. Both of the strategies have pros and cons. For instance people who change jobs quite often don't seem to care alot about the business per say they seem to emphasis on the technology more as compared to people who stick to one org. However, people who have changed job quite often, seem to have seen broad variety to problem sets and always bring fresh new pair of eyes to existing business. People who stick to the same org, do tend to become very conservative but it often good for the business as people not quitting brings lot of stability. Again, it really depends on situation, person to person. In general this is my observation.
Things I’ve learned in my 20 years as a software engineer
151–160 of 745 posts
Re: Things I’ve learned in my 20 years as a software engineer
#152> 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the more you realise you were wrong. Having an opinion has often come to mean one is a fan boy of something and will have it no other way. I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all cu…
The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top. PHP and node come to mind immediately. Ruby is down right retarded with promoting Concerns for modeling c…
> Dealing with python environments and packages makes me want to avoid python if at all possible.
I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow.
Quick rundown:
- don't use python2. Ever.
- don't use the system python, or brew python for anything other than bootstrapping
- only use `pip install --user` for exactly one thing: `pip install --user pipx` when you don't have brew
- never, ever, ever `sudo pip` anything. No exceptions.
- use pyenv to manage your python versions.
- use `pipx` to install stand-alone CLI tools, like virtualenvmanager, poetry, black, mypy.
- always develop in virtualenvs. No exceptions
- prefer installable python packages over scripty standalone .py files
- using PYTHONPATH is a smell
- poetry is likely the future of tooling, but it's not mature enough to be considered best practice for python beginners just yet. Stick with pip if you are uncertain.
- use lockfiles for writing applications but not writing libraries
- editable installs are a double-edged sword
Re: Things I’ve learned in my 20 years as a software engineer
#153Earlier quoted context omitted.
I think most people who have worked with me would consider me a 10x developer, I am capable of writing something in hours that would take others weeks (not in a half-arsed way, but taking all of the complexities of the domain into account). And I think that's what most people think a 10x'er is: that they can just do stuff quicker. That's not what I think 10x'er is though. I think a 10x'er is someone who enables the '…
In the fantasy organization where means justify ends, the 10x-er's time is better spent making the 1x-er obsolete. Your lip service to the 1x-er however does not go unappreciated as keeping him on and making him feel more productive is instrumental for political advancement, which is more important for your fortunes than the technical kind.
What an incredibly cynical view of the world. Teams where people collaborate are more successful, if you think trying to make your colleagues obsolete is time "better spent", I honestly feel sorry for your co-workers. Yes, if I sat and just wrote code all day I would get a lot done. But, if I help my colleagues too, we all get lots more done.
Re: Things I’ve learned in my 20 years as a software engineer
#154The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…
I think that depends on the context in which you’re working. Flashes of genius don’t have much place an an enterprise code base. Everything is rigorously standardized and separated into layers. Each layer has a bunch of bookkeeping about dependencies, interfaces, mocks, expectations, and test cases. This is not really brain work; it’s typing. Now maybe if you’re really brilliant, you’ll do much better than average wi…
Maybe that's why so many people think 10x programmers don't exist - they work in environments where a 10x programmer isn't needed and couldn't really demonstrate their skills.
Re: Things I’ve learned in my 20 years as a software engineer
#15540+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...
another 40+ here
w0rd!
Re: Things I’ve learned in my 20 years as a software engineer
#156Wish there was more philosophy of science and exploration into what "technology" means in CS programs. Maybe get undergrads to read Crime and Punishment by Foucault. Not saying he's the be-all end-all but just that perspective of seeing technology as subjective and situated in historical contexts. Technology in CS ends up instead being taught to be magical progress fuel that brings us towards the inevitable future ra…
I feel that programmers in general have a lot to learn from the postmodernists. Learning about social constructivism alone can teach you a lot about how to think about abstractions.
Re: Things I’ve learned in my 20 years as a software engineer
#157Expect always the worst case.
Don't assume anything.
If it is not the worst case, be happy, it saves you work. If it is the worst case, be happy, you expected it.
Re: Things I’ve learned in my 20 years as a software engineer
#158Earlier quoted context omitted.
I think most people who have worked with me would consider me a 10x developer, I am capable of writing something in hours that would take others weeks (not in a half-arsed way, but taking all of the complexities of the domain into account). And I think that's what most people think a 10x'er is: that they can just do stuff quicker. That's not what I think 10x'er is though. I think a 10x'er is someone who enables the '…
The way I see it: Developer: a person that creates software. 10x development: a person that does it 10x faster. What you describe, I'd simply call a lead developer since making other developers 2x or more is a lead developer his job. If you're a developer and you're doing this, then it'd be one argument to get promoted to lead. Also, if you really are a 10x dev, the one I know works in the HFT space. He's making bank…
Leading by example is not necessarily the same as being a lead developer. For example, my principal engineer is easily a 10x'er as just a pure developer, but he's also a force multiplier for everybody on the team, he's literally a machine. He leads no one, I made him principal engineer so he didn't have to.
If he was to just write code he'd be a 10x'er, with the other work he does to help his colleagues, he's many times more than that.
Re: Things I’ve learned in my 20 years as a software engineer
#159Earlier quoted context omitted.
>There is no "10X" touch-typist Ironically enough your example is flawed: there are documented 10x touch-typists. The realities of the court system place high demands on the typists; the minimum required typing speed is already quite high: trained court reporter or closed captioner must write speeds of approximately 180, 200, and 225 words per minute (wpm) at very high accuracy in the categories of literary, jury cha…
You make a good point that hints at another often-undefined assumption in these discussions - 10X performance vs who, exactly ? IMO, it should be vs "a typical peer in that profession". For court reporters, if "a typical peer" is a trained court reporter who averages ~200 wpm, and a superstar is at 300wpm, then it's a 1.5X gain. If a "typical peer" is a regular Joe, then 300wpm would be 10X - but this doesn't feel ap…
Fair enough.
I've had good luck discussing the subject back in 2013: https://news.ycombinator.com/item?id=6464807 and https://news.ycombinator.com/item?id=6465175, with the insightful replies.
Wow, reading the discussion from back then shows how much HN changed in spirit.
Re: Things I’ve learned in my 20 years as a software engineer
#160This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…
I've also met one 10x programmer in my life. A lot comes down to being able to reason fast, architect well, and write code on the fly without resorting much to: * Documentation * The debugger / print() Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.
So there are these moments in development, where the task boils down to ‘I just need to build this system. I can see it all in my head, and I need to turn it into code’
And for that task, factors like how well a developer knows the libraries, how fluently they can express themselves in the language, how fast they can type, how seamlessly their mental model fits with the tools available.. all of those things can make the difference between it being something one dev can crank out in a couple of days, and another dev takes a few weeks over.
And I definitely want more of the first kind of dev on my team than the second kind.
But here’s where that doesn’t match up to what we expect of lead developers and more senior devs as their careers advance, and why ‘10x’ is not necessarily an indicator of ‘ready for promotion’.
The person who can see the whole problem and turn it into code in 2 days often struggles to figure out how to scale what they do to more people. They can’t express how the code should work to someone else because they’re already three steps ahead - explaining how it needs to be done will take longer than just doing it!
So the problem is as soon as this person encounters a problem that is too big to fit all in their head and crank out in a few days, or that requires expertise they don’t yet have, so they need to collaborate… the approach they have learned to rely on stops working.
But it turns out there are 10x team leaders too - devs who can break large projects up into chunks that can be delivered separately, who make sure the team is building the right thing, who know how to make use of that individual who can just crank out a complex system in a couple of days - repeatedly and sustainably - and who make systems that are the right shape so that later features are cheaper and easier to add, rather than becoming harder and slower. In fact at this level the multipliers go way beyond 10x.
And some of those skills build on the individual 10x dev skill set but some are orthogonal to it. Some are downright opposed.