Thanks! We just happened to find a somewhat-critical error on Google Analytics and decided to pull the trigger ASAP to get it fixed. Shouldn't be too traumatic of a deploy :)
Awesome! Late night deploys suck, we have to in some cases to reduce user downtime. We had to recently migrate an entire AWS VPN - business team was "shipping their pants". It went fine with minimal downtime. Which leads to a question, when should Developers NOT tell business about some changes? I have found that sometimes they make things worse off than they should be.
A London Web Developer. A lot of my professional experience is in digital agencies and I enjoy helping new front-end developers learn how to code websites.
If they are asking, you don't need to say yes. If you need to get out the building before this, then they are not asking you, in which case you need to LEAVE THAT JOB!
I think the goal should be to get to the place where this isn't a big deal. Testing in production should be a thing. That's not a trolling comment, and I'm dead serious.
Get to where you can deploy multiple times a day, every day, all day.
For reference, read stuff by Charity Majors about observability.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
I understand the dread and I've felt it. I know I'm weird but writing tests or reverse engineering something is a great way to learn how something works :D
You're the second person to mention this in a few days. We (as in devs who don't share this dread) need to be better at communicating how to use these DBs because they are so important as you said 😭
I'm not sure if a CodeClimate plugin could check for this.
I do know that all Lambda Security products will scan for sensitive information but then you have to go serverless and pay for said service.
I like how Amazon Macie can detect (Personally identifiable information) PII and api credentials.
I guess if you're CI/CD is CodePipeline and CodeBuild which places artifacts (zip folders) of your codebase in S3 that maybe Macie could detect these issues. Uncertain if it can peak into zips.
I can relate to that, on my first "actual" full-time job, I had to work on code that was more than a decade old, written by someone who didn't believe in commenting code.
English lad currently a C#/Java/VueJs/JavaScript/TypeScript engineer.
Extra dribbling can be found at https://codeheir.com
Portfolio found at https://lukegarrigan.com
Inheriting a frontend that was a spaghetti of jQuery, Angular, jQuery UI, Bootstrap 2 and Bootstrap 3. It was a some pages SPA and some pages not, and globals everywhere. CSS was a hot mess.
My biggest accomplishments in that project were refactoring out Bootstrap 2, and making the JavaScript code modular the old-school way (this was before ES6) using Addy Osmani's JavaScript Design Patterns.
It's basically no different from a goto statement, and we've known for a long time that gotos are considered harmful. Applications which use events to drive data flow and logic become impossible to navigate, which makes them impossible to maintain.
I have a feeling there is a lot more to be said about this, and I think you maybe right and those architectures should be considered as anti-patterns. The biggest problem I find with event-driven stuff is how easy it is to lose track of what is happening, and how easy it is to introduce circular event triggering. I think the cleaner architecture would mean that it would be actually impossible to introduce a circular dependency. For example, it could be done similarly to the creation of objects. If you have classes:
It would be impossible to have a circular dependency such as above, because the creation of A's instance requires a B's instance, while the creation of B's instance requires an A's instance. So, you'll not be able to successfully run
leta=newA();// Error - need an instance of B as the 1st argumentletb=newB(a);
I think a similar way of thinking should be applied to events.
Wow. Want to hear more on this. I believe, not the architecture but the worst implementation which is harmful.
Event driven architecture works for many use cases.
You're exactly right, events by themselves are not bad, and can be very useful in large, modular codebases. But a bad implementation will only get worse over time, and the nature of it makes it nearly impossible to recover from beyond a certain point.
The problem is when the app is driven by events. When one event triggers another event, which triggers another, etc. One of the most extreme examples of this is WordPress, where in it's internals methods are rarely called on their own. They mostly call each other through events, which, while they can be augmented and overridden, means tools like static analyzers can't help, you don't have good stack traces, exception handling gets confusing. As a result, you really can't refactor that code anymore, since you can't really figure out who's all listening for the event anymore. But I've personally worked with many other examples in Android, JS, and PHP.
The alternative is to only use events as a reaction. Keep the logical path in normal function calls, send events as "notifications" instead, to broadcast what you just did or what you're about to do, without altering the execution flow.
Making a mistake that costs a whole heap of money. I've done it twice in my career - it's never entirely my fault but I've played a part. I'd really prefer not to do it again!
I feel you, but if you think that's bad, work as a designer, where everyone thinks design is about moving pixels around the screen 😄. Or everybody thinks that "I don't like it or I like that more" is good design feedback. I could continue, but not today 😆
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Taking a risk to improve some piece of code that has immense business value, and the thought of failing.
We have an Angular app that has been around for a long time. We are making plans to introduce ngrx to some of our core services so they cache data and improve our developer experience.
I'm the one person on our team with the most knowledge of ngrx, and its daunting.
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.
With the obvious proportion of the case, one of thing that makes me lose sleep is writing/reading code that does not express the intent, I call this: code which talks about code VS code which talks about business
Loosing my passion for coding (and computing in general).
Coding is really a passion to me but since I started working as professional dev I almost never code at home and I don't enjoy my professional projects as much as I used to enjoy the personal ones.
I sometimes feel like I'm wasting away my passion by having turned it into a job.
I definitely agree with you here, but on Friday evenings people can often get distracted with weekend plans. Then if something goes wrong with a deployment, asking people to stay late and resolve the issues can be hard (for everyone involved).
This can be challenging, and its why our team generally tries to avoid this (but it does happen sometimes).
I am a Software Developer for a top 50 Fortune 500 Company where my team specializes in Dev-Ops, by night I am a web developer trying to sharpen my skills and enhance my personal website project!
It happened to me not to long ago but using a Mongo function to clean a database and then wiping out all of the data luckily Mongo has an import function and we had a backup!
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
The SQL query to update user preferences for over 20,000 users in a production environment because you found a security flaw with something being saved in the database
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Working with spaghetti legacy code, and with customers that don't know what they want, or how to express it, so you have to help them to build their business, not only their website :/
Software Engineer @SciFY.
Live to learn something new -and write cleaner and more sustainable code- every day.
Passionate with learning and discovering new technologies, history, and psychology.
Max is a startup software engineer. He seeks to use what he has learnt as a startup founder and tech community leader to solves hard problems with innovate products or services.
Production releases on a Friday evening 😐
Doing this today. Yeah...
Good luck 👍
Thanks! We just happened to find a somewhat-critical error on Google Analytics and decided to pull the trigger ASAP to get it fixed. Shouldn't be too traumatic of a deploy :)
Hope you have some good CI/CD for that :-)
Yup! Jenkins rules :)
It didn't go as well as it could (some repo drama), but we managed to get stuff done. Yay!
Awesome! Late night deploys suck, we have to in some cases to reduce user downtime. We had to recently migrate an entire AWS VPN - business team was "shipping their pants". It went fine with minimal downtime. Which leads to a question, when should Developers NOT tell business about some changes? I have found that sometimes they make things worse off than they should be.
Been there, done that. Leave before they ask you to work weekends.
If they are asking, you don't need to say yes. If you need to get out the building before this, then they are not asking you, in which case you need to LEAVE THAT JOB!
I think the goal should be to get to the place where this isn't a big deal. Testing in production should be a thing. That's not a trolling comment, and I'm dead serious.
Get to where you can deploy multiple times a day, every day, all day.
For reference, read stuff by Charity Majors about observability.
Don't forget, "when a critical resource is starting two weeks' PTO the next day".
That's bringing it to a whole other level 😂
exactly :)
😆😆😆😆😆 great
A toxic unsupportive work environment.
Internet Explorer
I hate it so much.
Hopping into an already existing project that has no tests.
I understand the dread and I've felt it. I know I'm weird but writing tests or reverse engineering something is a great way to learn how something works :D
You shouldn't have to but still...
See it as an exploration adventure :D
110% this.
One Word: Databases :D
So important, yet so dangerous if you're not good at them.
You're the second person to mention this in a few days. We (as in devs who don't share this dread) need to be better at communicating how to use these DBs because they are so important as you said 😭
I’m ok at them after a couple years having to manage some, but with legacy DBs with bad tooling I get very nervous ;)
Pushing/releasing sensitive information/data 😰
I'm not sure if a CodeClimate plugin could check for this.
I do know that all Lambda Security products will scan for sensitive information but then you have to go serverless and pay for said service.
I like how Amazon Macie can detect (Personally identifiable information) PII and api credentials.
I guess if you're CI/CD is CodePipeline and CodeBuild which places artifacts (zip folders) of your codebase in S3 that maybe Macie could detect these issues. Uncertain if it can peak into zips.
Maintaining legacy code that someone else wrote years ago.
Especially if "someone" is a younger, less experienced version of yourself
I can relate to that, on my first "actual" full-time job, I had to work on code that was more than a decade old, written by someone who didn't believe in commenting code.
First refactoring would be to remove this comment.
Same. You can't put that there and expect me not to touch it. I can't ignore a challenge like that.
The comment is a warning from someone who tried to refactor.
I saw different variants of this, usually:
I die a little inside when I see this shit
Inheriting a frontend that was a spaghetti of jQuery, Angular, jQuery UI, Bootstrap 2 and Bootstrap 3. It was a some pages SPA and some pages not, and globals everywhere. CSS was a hot mess.
My biggest accomplishments in that project were refactoring out Bootstrap 2, and making the JavaScript code modular the old-school way (this was before ES6) using Addy Osmani's JavaScript Design Patterns.
Omg. This sounds like something FBI should use as a torturing interrogation tactics...😱
walking into a code base with:
I hope no poor soul ever gets the check to all those boxes, but I'm sure there are people who have!
I have a project that checks all but two of those boxes. Thankfully I have multiple environments and some build automation
My own code from 24 months ago 😱
That one gets me every time too! 😂
Event-driven architectures.
It's basically no different from a
goto
statement, and we've known for a long time that gotos are considered harmful. Applications which use events to drive data flow and logic become impossible to navigate, which makes them impossible to maintain.I have a feeling there is a lot more to be said about this, and I think you maybe right and those architectures should be considered as anti-patterns. The biggest problem I find with event-driven stuff is how easy it is to lose track of what is happening, and how easy it is to introduce circular event triggering. I think the cleaner architecture would mean that it would be actually impossible to introduce a circular dependency. For example, it could be done similarly to the creation of objects. If you have classes:
It would be impossible to have a circular dependency such as above, because the creation of A's instance requires a B's instance, while the creation of B's instance requires an A's instance. So, you'll not be able to successfully run
I think a similar way of thinking should be applied to events.
Wow. Want to hear more on this. I believe, not the architecture but the worst implementation which is harmful.
Event driven architecture works for many use cases.
You're exactly right, events by themselves are not bad, and can be very useful in large, modular codebases. But a bad implementation will only get worse over time, and the nature of it makes it nearly impossible to recover from beyond a certain point.
The problem is when the app is driven by events. When one event triggers another event, which triggers another, etc. One of the most extreme examples of this is WordPress, where in it's internals methods are rarely called on their own. They mostly call each other through events, which, while they can be augmented and overridden, means tools like static analyzers can't help, you don't have good stack traces, exception handling gets confusing. As a result, you really can't refactor that code anymore, since you can't really figure out who's all listening for the event anymore. But I've personally worked with many other examples in Android, JS, and PHP.
The alternative is to only use events as a reaction. Keep the logical path in normal function calls, send events as "notifications" instead, to broadcast what you just did or what you're about to do, without altering the execution flow.
Awesome point. Totally agree
Making a mistake that costs a whole heap of money. I've done it twice in my career - it's never entirely my fault but I've played a part. I'd really prefer not to do it again!
Management that thinks developing software is not a difficult task.
I feel you, but if you think that's bad, work as a designer, where everyone thinks design is about moving pixels around the screen 😄. Or everybody thinks that "I don't like it or I like that more" is good design feedback. I could continue, but not today 😆
Hahaha that!
Integration and its best friend: "It works on my computer!"
Its used to be merge conflicts, but nowadays I'd say it's when I can't find the freaking logs. I get real mad. haha
Unrecoverable database corruption including all the backups. Bye-bye business.
Taking a risk to improve some piece of code that has immense business value, and the thought of failing.
We have an Angular app that has been around for a long time. We are making plans to introduce ngrx to some of our core services so they cache data and improve our developer experience.
I'm the one person on our team with the most knowledge of ngrx, and its daunting.
I know the feeling
CONFLICTS, I just hate them. Especially if I can't reach the developer I am conflicting with.
Upgrading framework versions...
The possibility of a bug I don't know about silently altering or losing data across weeks to months to years without obvious failures or corruption.
My imposter syndrome stopping me from trying new things
With the obvious proportion of the case, one of thing that makes me lose sleep is writing/reading code that does not express the intent, I call this: code which talks about code VS code which talks about business
Loosing my passion for coding (and computing in general).
Coding is really a passion to me but since I started working as professional dev I almost never code at home and I don't enjoy my professional projects as much as I used to enjoy the personal ones.
I sometimes feel like I'm wasting away my passion by having turned it into a job.
When your engineering team doing such an amazing work and a non technical person calling out your team velocity isn't consistent!
Clients.
I hate the following scenario (which I've been part of many times in the past):
them: Here's a new urgent project. How long will it take to build it?
me: 2 weeks for a hack, 3 weeks to get it right. When is it needed?
them: We've already sold it, billing has gone out and we promised to deliver it last Thursday.
me: So, what is my drop-dead delivery date?
them: Last Thursday.
I definitely agree with you here, but on Friday evenings people can often get distracted with weekend plans. Then if something goes wrong with a deployment, asking people to stay late and resolve the issues can be hard (for everyone involved).
This can be challenging, and its why our team generally tries to avoid this (but it does happen sometimes).
Testing...
Unrealistic time expectations for work being done. Turns something I love into something I hate.
It happened to me not to long ago but using a Mongo function to clean a database and then wiping out all of the data luckily Mongo has an import function and we had a backup!
Hardware flaws that present as intermittent, inexplicable errors.
Basically, errors coming from below the lowest level I can inspect.
Upstream breakage {yells at cloud}
Screwing up authentication and leaking data.
Deadlines and bad project spec.
Hmm. That's a tough one. How do I choose? Well, if I had to pick just one it would have to be bees. As a coder, bees are my worst nightmare. Bees. 🐝🐝🐝
That tomorrow I won't remember anything about code.
That I'm not as good of a coder as I think I am, but no one will tell me or point me in the right direction.
Scope Creep 💀
The SQL query to update user preferences for over 20,000 users in a production environment because you found a security flaw with something being saved in the database
That's so exhausting :(
changes of business processes on last minute.
Intermittent Bug, that's creepy shit
The interview process
Critical, process-blocking bug that I cannot reproduce in local...
Spending 3 hours trying to find a bug only to find out (after checking stack overflow) that its like one line of code and super easy fix.
When I was an employee my biggest nightmares were technology choices made by other people which I had to live with.
Failing my customers. One of the worst feeling in the world is making a breaking change that hurts my customers' usability and their bottom-line.
Any day I wake up, I could wind up down a rabbit hole which could ruin the day.
Code written for concision rather than readability/Coders writing "clever" code.
It is far more valuable to have readable code than concise code.
"Don't worry about the backup, it's only a minor release".
Trying to raise your test coverage by 0.6% so that your PR is merged
Also being a blocker to someone's task.
Having to work on a framework/language that I strictly dislike.
This might show my age a bit, but the requirement:
“Application must support Firefox And IE6. “
Not being allowed to code.
Typescript.
Clients...
Even better, a memory leak in your code you deployed in AWS causes misconfigured auto-scaling to run up a bill of $10,000 in one day
Currently doing onsite tech support at an event on an app I didn't build in a language I'm not familiar with 😂
writing codes.
doing worthless, time-consuming computer programming.
This.
youtube.com/watch?v=eUHBPuHS-7s
Change.
Deploy in production the Friday at 4PM for 5PM.
Working with spaghetti legacy code, and with customers that don't know what they want, or how to express it, so you have to help them to build their business, not only their website :/
Writing something that accidentally gets someone actually hurt, or worse.
That something is wrong with my eyes and I can't see the screen correctly, or my wrists/hands hurt too much to type.
A light themed IDE
Having to build a strict XML data pipeline in Python or JavaScript.
Back when I was a Java code jockey at a startup: my boss talking to a potential customer.
All the changes that are still yet to add and push but suddenly computer going haywire and boom start from scratch.
Patching C++ recursive functions with goto's inside.
jQuery abuse ...
A huge major bug in a project I am the only developer, happening while I am on vacations... :(
Customer complaint on a Friday evening :)
Everything 😭
Fixing production bugs on a weekend 😞
If everything I've ever done gets hacked, even the stuff I haven't put online.
We have a product demo tomorrow please get XYZ out by then.