3 ms·

What makes me fast is I press Control-S and my code is live--working--in production. Clients love it. You have an idea--I make that idea work while we're on th

What makes me fast is I press Control-S and my code is live--working--in production. Clients love it. You have an idea--I make that idea work while we're on the phone. Slow devs have six layers of red tape between their code editor and the production server (version control, dev servers, prebuilds...) and they call that agile. Fast devs keep it simple. Fast devs are not afraid of their code, they know what to do. Code works the first time, most of the time. That's a good feeling. With experience, you're confident, most changes are easy and predictable.

untog 12y ago
What makes me fast is I press Control-S and my code is live--working--in production. Clients love it. One day they won't. I guarantee it.
leesalminen 12y ago
I don't use the Grunts, LESS, and asset pipelines like most "cool" devs, but Git is 100% worth the effort. From side projects, to enterprise, to my own start up, Git has saved my butt more than once.
- mod 12y ago
  Outside of the "saving my butt," like saving dozens/hundreds of hours of re-writing (probably by enforcing a backup copy of deployed code), I find git helps me gain time in numerous other ways: 1. git blame 2. git log (to re-assert where I left off, among other things) 3. git diff before a commit helping me to remember to remove test/debug code 4. github/gitlab etc search features occasionally I wouldn't dream of going back to a non-git workflow. PS: less/sass are cool. not necessarily time-savers but they make nice, clean css source.
- iseedeadpeople 12y ago
  Absolutely. I can't even imagine not using git, let alone version control. The time saved and improvement in process pays much more than you put in by learning it.
sharmi 12y ago
I doubt you have worked for long and experienced atleast one episode of the cleanup following a substantial damage. If you are really as fast as you claim you are, I suspect you have never worked with anyone before :)
- mathgeek 12y ago
  This was also my first thought. Statement like "fast devs are not afraid of their code" are a huge red flag that someone has little to no experience working on a team.
- pjbrunet 12y ago
  Been writing code for 30+ years. I did devops for OS/2. I have seen stuff break, like when Media Temple had a cluster fail and their backups failed. Which is why you always do nightly offsite backups. I never trust a host's onsite backup because they often fail. However, digging into backups for code never happens because with experience you learn how to introduce changes. Also remember, there's a 3rd and 4th backup copy: control-z plus the copy on the production server. 5th backup copy if you count your code editor's backup copy. 6th backup copy if you count the hosts onsite backup copy. And because I use Linode, that means 4 archived backups. So yeah, that's about 9 backups, just in case I forget a semicolon ;-)
  - mod 12y ago
    Damage can go far beyond "I can't find the old code." The consequence of failures vary drastically with the type of business you're developing for--if you're just developing wordpress sites for mom & pop flower shops, your advice sounds pretty solid.
  - sharmi 12y ago
    I dont even have a quarter of your experience. I do realize we have multiple backups either intentionally or unintentionally. But one thing I found when I don't check in code, and unfortunately have to resort to one of the backups, is that a lots of time is spent finding out which is the latest and has all the changes. Under really unfortunate circumstances, I have ended up with different copies of the code having portions of the latest features and having to merge. I have also had the bad fortune of cursing myself for deleting a code file unintentionally and having to rewrite it from some other unfinished copy. Makes me love version control systems. I always use one even for my personal projects. That is my recipe for coding without fear. YMMV.
smoyer 12y ago
I used to routinely work on code that could incur several millions of dollars per hour liability if the code was wrong (or even inoperable). I'm all for continuous delivery BUT you only deliver if your regression tests pass. If you deliver, your monitoring systems will roll back if problems are detected. I'd strongly recommend you put at least one layer of "controls" between you and production ... agile (to me) is the lack of BDUF ("architect astronaut") but does not advocate "cowboy coding".
- pjbrunet 12y ago
  I agree we need extra careful people doing those important jobs. Most websites, they don't even want to pay for a failover server. So every market has different expectations.

untog 12y ago

What makes me fast is I press Control-S and my code is live--working--in production. Clients love it. One day they won't. I guarantee it.

leesalminen 12y ago

I don't use the Grunts, LESS, and asset pipelines like most "cool" devs, but Git is 100% worth the effort. From side projects, to enterprise, to my own start up, Git has saved my butt more than once.

mod 12y ago
Outside of the "saving my butt," like saving dozens/hundreds of hours of re-writing (probably by enforcing a backup copy of deployed code), I find git helps me gain time in numerous other ways: 1. git blame 2. git log (to re-assert where I left off, among other things) 3. git diff before a commit helping me to remember to remove test/debug code 4. github/gitlab etc search features occasionally I wouldn't dream of going back to a non-git workflow. PS: less/sass are cool. not necessarily time-savers but they make nice, clean css source.
iseedeadpeople 12y ago
Absolutely. I can't even imagine not using git, let alone version control. The time saved and improvement in process pays much more than you put in by learning it.

sharmi 12y ago

I doubt you have worked for long and experienced atleast one episode of the cleanup following a substantial damage. If you are really as fast as you claim you are, I suspect you have never worked with anyone before :)

mathgeek 12y ago
This was also my first thought. Statement like "fast devs are not afraid of their code" are a huge red flag that someone has little to no experience working on a team.
pjbrunet 12y ago
Been writing code for 30+ years. I did devops for OS/2. I have seen stuff break, like when Media Temple had a cluster fail and their backups failed. Which is why you always do nightly offsite backups. I never trust a host's onsite backup because they often fail. However, digging into backups for code never happens because with experience you learn how to introduce changes. Also remember, there's a 3rd and 4th backup copy: control-z plus the copy on the production server. 5th backup copy if you count your code editor's backup copy. 6th backup copy if you count the hosts onsite backup copy. And because I use Linode, that means 4 archived backups. So yeah, that's about 9 backups, just in case I forget a semicolon ;-)
- mod 12y ago
  Damage can go far beyond "I can't find the old code." The consequence of failures vary drastically with the type of business you're developing for--if you're just developing wordpress sites for mom & pop flower shops, your advice sounds pretty solid.
- sharmi 12y ago
  I dont even have a quarter of your experience. I do realize we have multiple backups either intentionally or unintentionally. But one thing I found when I don't check in code, and unfortunately have to resort to one of the backups, is that a lots of time is spent finding out which is the latest and has all the changes. Under really unfortunate circumstances, I have ended up with different copies of the code having portions of the latest features and having to merge. I have also had the bad fortune of cursing myself for deleting a code file unintentionally and having to rewrite it from some other unfinished copy. Makes me love version control systems. I always use one even for my personal projects. That is my recipe for coding without fear. YMMV.

smoyer 12y ago

I used to routinely work on code that could incur several millions of dollars per hour liability if the code was wrong (or even inoperable). I'm all for continuous delivery BUT you only deliver if your regression tests pass. If you deliver, your monitoring systems will roll back if problems are detected. I'd strongly recommend you put at least one layer of "controls" between you and production ... agile (to me) is the lack of BDUF ("architect astronaut") but does not advocate "cowboy coding".

pjbrunet 12y ago
I agree we need extra careful people doing those important jobs. Most websites, they don't even want to pay for a failover server. So every market has different expectations.