> So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot
Following best practices will make it impossible to think outside the box (limits the creativity).
Software engineering topics I changed my mind on
381–390 of 704 posts
Re: Software engineering topics I changed my mind on
#382> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…
I think it is important to point out at this point, that product managers and project managers are two different jobs. Yes, neither writes code, but the product manager focuses on which features are most important for the customer and therefore needs to know a lot about the product and what makes a good product.
Project managers, on the other hand, can be used even if there is no product. They require good people skills and (should) make things work, while having some knowledge about tools/methods that could enhance the job.
If you think SCRUM, the project manager is closest to the scrum master (someone who cares about impediments and methodology) and the product manager is likely to be the product owner (prioritizing and describing features).
However, project managers can be used for all types of assignments as long as they have a start and an end ;-)
Re: Software engineering topics I changed my mind on
#383I'll add after 20+ years:
- Being able to communicate ideas > Being a great technical developer
- For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule".
- Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to challenge assumptions and break through with new skills.
- TDD is a skill just like refactoring. Learn when it makes sense.
- 80% of architects in enterprise don't have the skills needed from them. including the things stated above.
- Learning the Theory of Constraints and applying it to find bottlenecks in the process, pipelines and structures of your teams/projects is one of the most useful things you can apply to become more productive.
- Learning what to measure and what not to measure, lagging vs leading indicators can help you communicate to management about what changes truly need to happen to make your team work more effectively.
- Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.
Re: Software engineering topics I changed my mind on
#384Earlier quoted context omitted.
Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…
> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.
status report = you have to take responsibility for what you have done (or not done)
state what you are doing = what happens automatically if you sit in the same office with other programmers: you know what they are working on, you know if they are stuck with something because they usually just ask aloud, etc.
Re: Software engineering topics I changed my mind on
#385> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements…
> Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds
Virtually each time I've been interviewed myself the attitude was not to find out what my strengths are, but to discover gaps in my knoledge and skills. I think that's the standard in our industry. Sadly, this is exactly the oposite of what companies should be looking for. They need people who can do the job, and knowing some obscure (or even popular) algorithm by hreat or some rarely used programming language feature has nothing to do with it.
Re: Software engineering topics I changed my mind on
#386Earlier quoted context omitted.
> So while FP is just another tool, it's also a framework for thinking that helps people make better choices I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me. Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of fun…
I agree that separating logic from side-effects is an excellent lesson that easily translates to less functional programming languages. Another thing I tend to do now is order function arguments as if the programming language had partial function application. You can see this in JavaScript by comparing lodash to lodash/fp. I think once this practice is established on a team, it can help bring a more uniform feel to t…
In javascript it's pretty easy to write a function for partial application in either order, you can curry functions forward or backward.
const map = (arr, mapper) => arr.map(mapper); // Non "traditional" order for arguments
const curry = f => (...first) => (...second) => f(...first, ...second); // Classic currying: partially apply arguments to the start
const reverseCurry = f => (...second) => (...first) => f(...first, ...second); // You might want to reverse() first and second depending on the desired syntax
const arrayMapper = curry(map)(array); // Usually not that useful, more common to map over many arrays with the same function than to map over the same array with many functions
const funcMapper = reverseCurry(map)(func); // Same benefits as having the classic argument order in the first place
Re: Software engineering topics I changed my mind on
#387Earlier quoted context omitted.
If I had a dollar for every senior engineer I've worked with who has never heard of SQLite...
Truth be told I am yet to see a reason to use in-memory database. Datstructures, maps/trees/set - yes. Concurrent/lock free/skip lists/whatever - all great. I don't need a relational database when I can use objects/structs/etc.
I think that depends on what you're doing with the data. If you're just grabbing one thing and working with it, or looping through and processing everything, maybe not.
But if you're doing more complicated query-like stuff, especially if you want to allow for queries you haven't thought of yet, then the DB might be useful.
Sometimes a hybrid of query-able metadata in a DB along with plain old data files is good.
That depends very much on your data, how much things key to each other, and what you're doing with it.
Re: Software engineering topics I changed my mind on
#388Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful,…
In a lot of cases Microservices are the cheaper option. Keeping your code in a monolith requires a lot more investment in tooling (to manage a large monorepo, because apparently our industry has collectively forgotten that you can actually build separate libraries and keep them in different repositories) and coordination between multiple teams working on a single large project. The simplest solution is often for mana…
That is what I am usually annoyed by when reading discussions like that. Someone assumes a context and throws in his experience like it would be applicable to every company and every project. Using their own definitions for industry buzzwords and by that making it more confusing for others, where those others start doing the same again as a response which brings nothing to the general understanding of things.
When reading article I assumed author was not going to tackle project with multiple teams. I expect he was writing about a lot of projects that don't ever live to need more teams. You have a lot of projects where you have 10-15 devs as one team on it and those are huge projects but there are no downsides of a monorepo because it still works fine and is single repo/application.
I would say monorepo should be defined as: repo where you have all projects for a company that don't need to be linked in any way. Because what I understand gave start to the term was Google having such use case, where they wanted ALL things in one repo.
Having one project in one repository cannot be named "monorepo" that is just normal repository and that's what monolith in a single repo is.
Re: Software engineering topics I changed my mind on
#389Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things:
> Clever code isn't usually good code. Clarity trumps all other concerns.
My measurement is "simple and clean" code. Is it simple and clean? No? make it so!
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.
If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough.
One last thing I like to remind myself: "Good enough is always good enough". Sometimes "good enough" has a low bar, sometimes high. You always need to reach it, but never want to go too far above it.
Re: Software engineering topics I changed my mind on
#390I'll add after 20+ years: - Being able to communicate ideas > Being a great technical developer - For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule". - Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to c…
> Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.
I agree that it's great to have a visualization aid, especially in remote meetings. But in my experience, for the needs of most meetings, Miro boards are a cumbersome, over-featured sink of time and effort. Then they invite you to leave them standing as sole documentation of the details of a meeting's outcome, which they're not very good at. Use them wisely!