742 karma · joined December 8, 2015
Gitflow has 2 major problems: - develop branch that will always become a mess over time - release branches are never completely accepted. It is much easier to accept features branches.
We try to merge feature/bugfix branches directly to master when they are approved.
We have testing/staging branches that can be thrown away and re-created from master and re-merge any feature/bugfix branches that have to be checked.
This has worked very well for the last 5 years or so and we have used it in dozens of projects every year.
The fact that testing/staging contains no commits (except merge commits) of its own is very useful. You can drop these branches regularly and remove any old feature branches that became stale for some reason.
Lastly, I have seen a lot of teams that want to apply complicated Git strategies from day one of a project where it would be much better to just work on one master branch because too much code changes at the same time. This will create complicated conflicts. The history at the start of the project is not interesting. Git history only becomes useful when the project is live and you want gradually add features or fixes.
We make websites according to the latest fad and all your work will be thrown out when the business decides to change agency, framework or rebuild everything in some marketing automation tool. I've worked in an agency for almost 10 years and I have accepted that fact.
No matter how beautiful your code is, most web code is thrown away after a couple years anyway. It is just has to do what it is supposed to do, nobody cares about the code.
Agencies also deliver spaghetti code, what is the definition of that anyway? All code is spaghetti in some way. All real code is a mix of different styles and approaches. It will be a mix of OOP, Functional, declarative, imperative code. It is all custom build by different people with different backgrounds.
If you want to work on a more structured codebase then try applying to a company who have 1 product and 1 big codebase. You are likely to find much more structured code there because organising codebases take a lot of time and effort. For a larger codebase with more people working on it things like design patters, rules, best practices, linters and tests will become useful and teams will add then over time.
You will not easily find all of that in web development simply because there is no budget for it. There is only 1 goal in web development. Add as much business value in the least amount of hours.
You can be proud on what you delivered for the businesses you worked for. You solved their problems and you created value for them. No matter what the code looks like. As long as it was secure and it worked then it was perfect for what it was supposed to achieve. Don't be so hard on yourself.
The 2015 MacBook Pro is just superior and I am very hesitant to buy a new one. I just want this model with better specs.
We also sent them out sailing by themselves all day across the lake. They have to navigate and set up their tent on the sailboat themselves. We only check up on them once before nighttime and then sail back to our own campsite, which may be an hour or more by boat. The next morning they pack up their stuff, prepare the boat and set sail to travel back to the campsite (half-day sailing depending on the wind conditions). The oldest boy (14-15 years old) is in charge and has to bring everyone back safe. Some of my best memories are surviving and being responsible for the other kids. You have to take care of them, teach them and protect them.
These days they have a mobile phone, so in case of an emergency, they can contact the grown-up leaders. But in my time we got a couple of coins for a payphone and we were also fine.
It reminds of te Smurf language where they can use "smurf" and variants of it as a general name for a person, replace verbs and adjectives. The meaning is highly contextual.
But it is very common that a developer can fix a problem or build something 10x or even 100 times faster than others. Simply because they know the project, the language, understand the problem already, have experienced that problem before.
I have many anecdotes where I was stuck on something for hours and a colleague solved it in 10 minutes. But I have also counter anecdotes where 2 colleagues were stuck a whole day trying to solve a problem while I was out of the office and the next day I solved it in less than 5 minutes. The multiplication factor of that is insane, but it really happened.
I now call them technical frontend developers and visual frontend developers during interviews. I am not sure what terms will stick in the end.
Our senior frontenders handle both the technical and the visual part.
We have some experienced senior full-stack developers who can work on anything from hosting, server-side code, client-side business logic in React, but they usually stop there and let visual frontenders implement the design.
Observing our junior frontend developers I noticed it is very difficult to be effective in both areas. You really need years of experience before you can grasp the whole thing.
Managing state and business logic is so different from implementing a design. It requires very different skills. I can really sympathize with traditional visual frontender feeling overwhelmed with the whole javascript madness that is going on. Companies who just dumped it on them because "it's frontend", are making a huge mistake.
Our society is fastly moving towards a feudal system. It will not take long until everything is owned by rich overlords.
I am a bit surprised that multiple people here are living in such a permanent state of paranoia.
Yesterday on the news it was said that the Green parties in Europe have the future because half of the young voters (18-25) voted for progressive parties, but they forgot that in 5 years they will all be at the age of starting a family and will vote much more conservative.
Same with food delivery companies. The drivers have to provide and maintain the vehicle, organize their own health care, pension and insurance. Some companies even disallow them to work for different companies, which is a direct violation of the contractor dynamic. Recently a Dutch judge ruled that these food delivery contractors were not actual free agents but bound to their one supplier of rides. The judged ruling was that this is not correct as they lacked the freedom to work for other companies.
I find it very disappointing that companies like Uber and Airbnb managed to create these amazing platforms but have such disrespect for the wellbeing of their workers or how they affect communities in the world.
There is also a big chance that Facebook, Google or whoever will drop their project at some point leaving you hanging and having to rewrite everything again to native or the next multiplatform framework.