It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Some overtime or off-hours stuff is more or less de rigueur in this industry, but expectations should be clear up front and the company you work for should respect your time. Never work for free.
Think about the impact your work will have and whether you'd be happy to sign your name to it. You can't eat standards but it's good to have them.
Hierarchies are efficient but can be working efficiently at cross purposes with you. The flipside is that they're brittle; sometimes it's easier to ask forgiveness than permission. The trick is in anticipating and managing the risks and consequences involved.
If you have to do the same thing more than twice, consider automating it.
Consistent, highly available, partition tolerant: pick two, depending on requirements. Cheap, reliable, fast: pick two, depending on requirements. Clever or maintainable: pick one, and there's a correct answer.
Reporting a problem you've discovered is good, thorough analyses are better, proposing a solution is best. It doesn't have to be right, it just has to start the discussion.
Everything everyone has ever written about "agile" boils down to "more and shorter feedback loops". It's a good idea but shouldn't be over-complicated. Adapt processes to fit people: people may be the squishy part of the equation but we aren't liquids and don't take the shape of our container.
Pay attention and put some effort into how you communicate, especially in contexts where you can't rely on facial expressions and body language to add nuance. It's easy to make assumptions about what other people know and feel and easy to come off differently than you intended, and it's rarely for the better.
Every Turing-complete programming language is a different method of expressing the same fundamental formulations and processes, and understanding the general principles underlying them is more important than the ability to navigate any one system (& the former is arguably a prerequisite for doing the latter well). The specific language you're working in is essentially a matter of taste; the concepts always map across one way or another.
Crap code in prod makes you more money than elegant code you haven't finished yet, but by the same token there's nothing so permanent as a temporary kludge.
For all the stereotypes of hyper-rationality, software people really, really love fads and often overlook limitations or issues that make their pet idea a bad fit for what they're trying to do. The current overuse of blockchain only proves we didn't learn the real lessons from NoSQL or microservices.
Object/relational mappers are more trouble than they're worth.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some overtime or off-hours stuff is more or less de rigueur in this industry, but expectations should be clear up front and the company you work for should respect your time. Never work for free.
Think about the impact your work will have and whether you'd be happy to sign your name to it. You can't eat standards but it's good to have them.
Hierarchies are efficient but can be working efficiently at cross purposes with you. The flipside is that they're brittle; sometimes it's easier to ask forgiveness than permission. The trick is in anticipating and managing the risks and consequences involved.
If you have to do the same thing more than twice, consider automating it.
Consistent, highly available, partition tolerant: pick two, depending on requirements. Cheap, reliable, fast: pick two, depending on requirements. Clever or maintainable: pick one, and there's a correct answer.
Reporting a problem you've discovered is good, thorough analyses are better, proposing a solution is best. It doesn't have to be right, it just has to start the discussion.
Everything everyone has ever written about "agile" boils down to "more and shorter feedback loops". It's a good idea but shouldn't be over-complicated. Adapt processes to fit people: people may be the squishy part of the equation but we aren't liquids and don't take the shape of our container.
Pay attention and put some effort into how you communicate, especially in contexts where you can't rely on facial expressions and body language to add nuance. It's easy to make assumptions about what other people know and feel and easy to come off differently than you intended, and it's rarely for the better.
Every Turing-complete programming language is a different method of expressing the same fundamental formulations and processes, and understanding the general principles underlying them is more important than the ability to navigate any one system (& the former is arguably a prerequisite for doing the latter well). The specific language you're working in is essentially a matter of taste; the concepts always map across one way or another.
Crap code in prod makes you more money than elegant code you haven't finished yet, but by the same token there's nothing so permanent as a temporary kludge.
For all the stereotypes of hyper-rationality, software people really, really love fads and often overlook limitations or issues that make their pet idea a bad fit for what they're trying to do. The current overuse of blockchain only proves we didn't learn the real lessons from NoSQL or microservices.
Object/relational mappers are more trouble than they're worth.