phuff
The agilists I think ended up having pretty good answers for finding a sweet spot between small iterations that maintained quality while minimizing Big Design Upfront to prevent spending a lot of time preplanning the software, allowing a well functioning agile team to maintain reasonably high quality, extensibility, maintainability and satisfaction of actual customer needs while keeping velocity high and not getting bogged down in design heavy tar pits which were ended up not fully anticipating problems encountered during actual execution.
If that doesn't sound like a buzzword filled sentence I never expected to come out my mouth... But. The bottom line is: if you can keep your execution goals small and focused enough, you can iterate quickly towards a design with better information than you would have if you were to do a design study because you'll be better informed by the actual needs of the execution process than by what you _think_ the execution process will require at design time.
Are we at the point yet where we might be able to replace some of these legacy Fortran libs with more modern, legible, performant Rust or C/C++?
Counterpoint: Most workplaces would be best served by a team of developers who help up level each other without causing morale issues when knowledge gaps, which everyone has, inevitably show up.
This type of environment is the best for software development organizations specifically because most software development shops that have more than one person working on a codebase or system or set of systems have already reached the point where no single person can keep the whole thing in their head at once.
Maybe that person really worked in an environment where they didn't have to think about pointer arithmetic. Reframing closing knowledge gaps as a beneficial and necessary part of a healthy development system makes it so when somebody doesn't know something and needs help they are willing to get it quickly. And that they will talk about knowledge gaps openly so they can be filled with the collective pool of the organization .
Shutting that down even by just "narc-ing" on the person just makes it that much harder when others need to know something they don't to get a job done, slowing down the system over time.
I came here to talk about this, like some other commenters did, too :) I think that this _is_ a predominant view amongst most of Silicon Valley but I think it's kind of a local maxima view... Easy to agree with, easy to see that it's a functional idea, but... people... (i.e. consumers) do lots more than just waste time on their phones even though I bet that's a huge amount of what people are doing across the US right now.
I guess the thing that _is_ true about this nugget is the "at scale" part. It's hard to find things _at scale_ that people would pay for on a phone. So the phone sort of falls back into this easy to monetize thing via advertising. But I think people (qua consumers) probably can clearly be a sustainable market for way more than attention harvesting (or dopamine fracking!) but it requires a lot more effort to think of things that you can build a market out of there. So people sort of lazy-back into attention harvesting via ads.
Seems like this is pretty clearly a case of fraudulent misrepresentation (https://www.law.cornell.edu/wex/fraudulent_misrepresentation) which kinda nullifies the contract, if I understand correctly:
Fraudulent misrepresentation is a tort claim, typically arising in the field of contract law, that occurs when a defendant makes a intentional or reckless misrepresentation of fact or opinion with the intention to coerce a party into action or inaction on the basis of that misrepresentation.
To determine whether fraudulent misrepresentation occurred, the court will look for six factors:
A representation was made
The representation was false
That when made, the defendant knew that the representation was false or that the defendant made the statement recklessly without knowledge of its truth
That the fraudulent misrepresentation was made with the intention that the plaintiff rely on it
That the plaintiff did rely on the fraudulent misrepresentation
That the plaintiff suffered harm as a result of the fraudulent misrepresentation
Like most claims under contract law, the standard remedy for fraudulent misrepresentation is damages.It does make me scared for what other dangers lurk since this was a really bad one and it was so little work to find.
Also of note: so many security issues lately have been done using AI. This report makes me think two things:
1. Expertise is still immensely valuable, the more niche, the more valuable.
2. There are lots of niches still where AI doesn't dominate...
So you had to go to the lab to find a computer beefy enough to do your work on.
It's not a home "lab for experimentation.".
It's a home "lab for getting work done."
Additionally, you seem to have diagnosed yourself as having a skill deficit with interviewing. This is also a great position to be in. If you want to work on interviewing, which based on your message it sounds like is your weak skill, then invest time (and maybe money) in practicing that skill with the added understanding you have (and skills you are building) about your managing your ADHD.
One way to think about this is to treat interviewing as a separate skill set; there really are lots of online resources that teach you to interview these days. Practice interviewing as a separate skill set.
You can invest in this skill with money; leetcode and other sites really package this as a service. The benefit to you is not that they will grant you a job offer; it's that they will grant you the opportunity to practice in low stakes environments. There are also places online that are pairing people for interview practice.
You can also reach out to people you have worked with previously and say: I want to practice interviewing; would you spend 30 minutes with me doing a mock interview? People love to help each other.
At the same time continue to invest in managing and understanding your ADHD by working with professionals to develop those skills. Combine the two and some time and you can do this.
You'll get this. Hang in there! Feel free to email me if you would like to talk more.
Here you have an app on everybody's phone that is such a useful tool that the government isn't even thinking to turn off in the middle of a war even when it's providing real time intelligence in the open about what is happening on the ground.
This seems like a great example of how openness in technology can overwhelm even one of the least Democratic governments through transparent infrastructure.
I bet when they were building Google maps back in the early/mid 2000s they never thought their tool would be used for real time tactical war reporting on civilian and troop movement.
I think over time (say the next 5-10 years) there will be upward pressure on remote salaries and eventually they will normalize to being approximately in the same range as the Silicon Valley ones because of economic pressure: everybody is still going to be competing for workers everywhere. The competition is simply going to get bigger as firms realize they can hire top talent from other places and they need to in order to find and keep the best people.
From the lens of the internet as means of disintermediation in society this makes sense. Using this framework to reason about the internet, we might think of different ways that the internet removes barriers to communication; recently there are several social phenomenon where the internet has removed geography as a barrier to communication enabling lots of different social changes. In this framework, salary and employment markets were just slowly going to eventually get geolocation disintermediated. The pandemic has just sped that up 5-10 years. Now instead of taking 10-20 more years it'll take 5-10.
You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.
I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.
If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.
As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.
And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".
But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.
We do billions of requests a day on one of the teams that I manage at work, and that team alone has sole operational and development responsibility for a large number of subsystems to be able to manage the complexity that a sustained QPS of that level requires. But those subsystems are in turn dependent on a whole suite of other subsystems which other teams own and maintain.
It requires a lot of coordination with a spirit of good-will and trust among the parties in order to be able to develop the organizational discipline and rigor needed to be able to handle those kinds of loads without things falling over terrible all the time and everybody pointing fingers at each other.
But! There are lots of great people out there who have spent a lot of time figuring out how to do these things properly and that have come up with general principals that can be applied in your specific circumstances (whatever they may be). And when executed properly I would argue that these principals can be used to mitigate the burnout you're talking about. It's possible to make it through those rough spots in an organization (that frequently, though not always, come from quick business scaling -- i.e. we grew from 1000 customers to 10,000 last year) etc.
If you're feeling this kind of feeling and the organization isn't taking steps to work on it, then there are things you can do as an IC to help, too. But this is all a much longer conversation :)
It works really well. It has the playlisting/queueing metaphors that I prefer and it has a decent interface for finding things or even playing all of the albums from a specific artist.
This and the .plan/finger posts from a few days ago are playing to the nostalgia of a better time on the internet. :). Iirc you could also do fully animated .plan files on VAXes at the time.
https://www.irs.gov/e-file-providers/free-file-fillable-form...
I'm hiring for several senior/staff engineering positions working on distributed systems in Erlang with some elixir, go, and exploratory rust sprinkled in here and there. If you're interested please feel free to send an email to the link in my bio.
I mean -- I kind of feel like if you're going to store your core business information in software, you're just going to have to deal with the fact that software has bugs. It's the nature of the beast. So, is it really something they owe compensation for?
Probably they owe a bugfix, that I grant you, but compensation? I mean I guess if there was an explicit contract for the feature that tied compensation to it I could see a good argument that they owe compensation. But do they owe compensation to the good people of Hacker News who are suddenly talking about DDOS-ing the feature? That seems like a much harder case to make.
Anybody with your hand raised should be ashamed of yourself because I bet it's not true :)
Sure they should fix this -- but is this something they should be fined for? Or be DDOS-ed by Hacker News readers? Or GDPR reported for?
It's just not a great way to get help from up and coming businesses to force major financial pain on them and it's certainly not empathetic to what's likely a hard working, reasonable set of people on the other end of this service.
https://github.com/phuff/epub_builder
I built it because I wanted to have something that made a daily brief news paper that was personalized and sent to my kindle. It makes an epub and uses kindlegen to convert it to a .mobi. There's a lot of fun epub formatting stuff you can do.
Here's the system that makes the daily newspaper, but it's been so long I'm not sure it's actually functional code outside of my production version:
For example: one large professional skill you have is this: "I've been able to always have work on my desk because I'm always moving and talking with people in the industry" combined with this: "I've always managed to solve the problems in front of me but in a 'hacky way'."
Those to things together say to me: "This person is able to communicate with others in order to solve problems" which is really one of the key differentiators between a more "senior" software engineer and a more "junior" software engineer.
I have some questions: Are you still at the company? If so I think you have a great opportunity ahead of you to improve some of your software design/engineering/crafting skills while leveraging some of your strengths.
If not, I think you should consider another medium sized company and not worry about this most recent experience as being the end of your software career.
Next question: The code that was filled with hardcoded values, wrong structure, difficult to debug bugs... was that your code or the existing code? If it's your code, then you're in a great position (like others have said) because you've already identified problems and so that's your list of things to work on next.
What does "failed to accomplish it" mean in terms of the task? The thing about software, especially at a company that's not going to go down in flames because of a problem you've failed to solve is that... you can try again. You can keep taking swings at the task until you figure it out and eventually knock it out. So that doesn't seem bad.
"I'm thinking about looking for semi senior roles but I'm afraid it'll look weird..." As a hiring manager who's been interviewing people in this industry for more than 15 years it never looks weird. And if it looks weird and you have something to offer and the company can't see past whatever "weirdness" that's their loss -- you sound like a thoughtful, introspective employee who's got an impetus towards self improvement. That's gold.
You could transition to PM, you could "take a break" -- but I'd want to think carefully about the answers to the first few questions if I were you because it sounds to me like you are interested in software development and are interested in self improvement in software development and if so it sounds to me like you have a great opportunity in front of you.
If you are still feeling lost, and actually make it to my message, hit me up at the email in my profile -- I would be happy to talk about it further in more detail.