Seriously though, do it, and learn how to. It's all too often you get a ticket or a project for someone which has 10,000 requirements (Ok a little exaggeration) and it may seem like a huge task up front and can cause excess stress. But breaking it down piece by piece, suddenly things become much simpler and easy to manage.
Albeit not directly developer advice but being able to look at a project and be able to break it down, but hey, being a developer is more than just programming :)
Very good point actually. I'm still in shock when I see experienced developers writing code on the fly like they know where they want to get and how they want to do it, but not having an actual written plan anywhere. I guess this skill comes with years and years of experience. I'm at the point where I makes schemas on pieces of paper, even for simple tasks :). Thank you for the advice.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
You really will learn to write code on the fly (which is a very bad practice TBH) when you start doing it.
You can get a portfolio and editing code directly on production from the hosting IDE or using vim (or whatever) through SSH, but there's no much adrenaline here.
Then you can edit the .htaccess or add a return true (or false) at the beginning of a method (for blocking this path, for example on a method that calculate some specific discounts, when you want to finish this promotion and marketing department tell you to do that quick because they didn't planned it properly), or for fixing a blocking bug. All of it on a web app that earn 10M a year and then the adrenaline appears (and your know-how to open the views where your changes will take effect on a secondary screen before saving changes and make a quick test to ensure you didn't broke it).
My best advice here is:
I'm conscious that supposedly we must never edit code on the fly or in production directly, but sometimes it's needed for a quick fix (it's instant while a deploy could take 10-15min at least). When you are in this situation ALWAYS add exactly the same changes on your develop branch, as the next time you make a merge from develop into master for a new feature, you will not face a manual merge).
Sort of on topic I guess. But also teach them that yeh. Being a developer isn't just developing :). Writing documentation, specs, debugging etc. Lots to programming other than code :)
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.
Break. The. Project. Down.
Seriously though, do it, and learn how to. It's all too often you get a ticket or a project for someone which has 10,000 requirements (Ok a little exaggeration) and it may seem like a huge task up front and can cause excess stress. But breaking it down piece by piece, suddenly things become much simpler and easy to manage.
Albeit not directly developer advice but being able to look at a project and be able to break it down, but hey, being a developer is more than just programming :)
Very good point actually. I'm still in shock when I see experienced developers writing code on the fly like they know where they want to get and how they want to do it, but not having an actual written plan anywhere. I guess this skill comes with years and years of experience. I'm at the point where I makes schemas on pieces of paper, even for simple tasks :). Thank you for the advice.
I find your comment kinda funny Silvia :)
You really will learn to write code on the fly (which is a very bad practice TBH) when you start doing it.
You can get a portfolio and editing code directly on production from the hosting IDE or using vim (or whatever) through SSH, but there's no much adrenaline here.
Then you can edit the .htaccess or add a return true (or false) at the beginning of a method (for blocking this path, for example on a method that calculate some specific discounts, when you want to finish this promotion and marketing department tell you to do that quick because they didn't planned it properly), or for fixing a blocking bug. All of it on a web app that earn 10M a year and then the adrenaline appears (and your know-how to open the views where your changes will take effect on a secondary screen before saving changes and make a quick test to ensure you didn't broke it).
My best advice here is:
I'm conscious that supposedly we must never edit code on the fly or in production directly, but sometimes it's needed for a quick fix (it's instant while a deploy could take 10-15min at least). When you are in this situation ALWAYS add exactly the same changes on your develop branch, as the next time you make a merge from develop into master for a new feature, you will not face a manual merge).
Totally agree. This is a very important skill Im trying to masterize.
Sort of on topic I guess. But also teach them that yeh. Being a developer isn't just developing :). Writing documentation, specs, debugging etc. Lots to programming other than code :)