4 ms·

2. Document the steps to setup dev environment in your own words and highlight the issues that you run into This is the most significant thing for me getting u

2. Document the steps to setup dev environment in your own words and highlight the issues that you run into This is the most significant thing for me getting up to speed on a new or old project. I absolutely hate reading some whacky custom dependency, jboss, hell like project setups. They just kill morale. And I feel really bad when I see new starters wade into the tall grass on this stuff. I can almost see the moment they go to lunch and start thinking about quitting tech. My personal reaction to being given really bad 'quick start' doco so many times, is to try and leave every project I work on in a state where "mvn clean install" will do everything needed to get things running. You may join a team, but your team is also getting a new member. They should be working HARD to make you productive asap, and crazy dev setup is like a code smell.

berkes 6y ago
I recently joined a new team and codebase. There was no 'getting started', no docs. I was left on my own. So I muddled through. And documented everything in Makefiles. Not readme, but working code. Now `make clean` `make install` etc, all run, deploy, install, clean etc the project. A great way to learn. But unfortunately worthless to others in the team, as they all were entrenched in their own ways and setups. I just added a sixth' way of 'working with the codebase'. I'm no to sure if it is the team, me, or Make, but I certainly won't spend such time a next new codebase arrives. (I do add makefiles on each of my private and opensource projects though, and will keep doing that)
- gonzo41 6y ago
  > they all were entrenched in their own ways and setups. I consider this a bad behavior. If people espouse the benefits of CI/CD and cattle over pets. Then I firmly believe that thinking needs to make it's way to the dev environment. And what you did isn't worthless, the next person get's to go quicker and spend effort on features that make money.
  - berkes 6y ago
    > I consider this a bad behavior. Part of it is probably that I fixed something that wasn't broken for them personally. I understand than when a new person joins and starts telling you that you should now start using this "new", "Makefile" thing, you'd probably be annoyed and get back to work instead.
- aidos 6y ago
  Your team sounds a little broken. If a new starter came in and did that for our project, I’d be really pleased. Once you have that stuff setup, and you’re doing “day to day” coding, it’s hard to find time to go back and sort that stuff out. It’s something a new starter can take on that ultimately gives good long term outcomes.
  - gabereiser 6y ago
    Exactly. Sounds like rot has settled in and there’s a serious lack of empathy for coworkers (who have to wade through that tall grass like those before did). Cut the grass. Better yet, pave it. Docker compose up your dev environment. Make it so going from clone->pr is as quick and painless as possible.
- adriancr 6y ago
  What I've done in the past and worked is as follows - learn from others what they are doing and why. It may look inefficient but there may be good reasons. - document everything / make sure your understanding is correct and others can follow your documentation and use the old flow. - start automating and improving while keeping existing things that worked still there. Doing things this way I was able to improve processes for very bureaucratic companies and have had people appreciate and put in their time to help once they started using.
- reidjs 6y ago
  What is the benefit of makefiles over bash scripts?
  - nemetroid 6y ago
    A Bash script is a linearization of the dependency graph, a Makefile is a description of the graph itself.
  - muskox2 6y ago
    - Make is a standard utility, so anyone that has used make before will know what 'make', 'make clean', etc will do without having to read any documentation. - Make has the ability built-in to only run certain commands based on the files that have changed, which can be handy. - Makefiles usually have a lot of handy variables for configuring the project like $CC or $DESTDIR. While you could have these in a bash script as well, there's a standard convention for variables in Make[1]. In my experience, Makefiles are usually better documented and follow more conventions than scripts. There are of course many exceptions to every rule. Make files are very similar to bash scripts, and while I would prefer a Makefile any day, it's really a matter of preference. [1]: https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html https://www.gnu.org/prep/standards/html_node/Makefile-Conven...
    - tharkun__ 6y ago
      I think we also need to be careful. The OP on this thread did not specify what kind of project. Make may be completely appropriate. It might also not be and just what they are used to. The proverbial hammer. If someone came in and tried to build my Java project with Make, I would definitely call them crazy and not use it either. If someone came to my Java project and tried to put Gradle on it to build it, I might also not use it but at least its appropriate for the language and if everyone on the team/project was OK with it, I would probably be OK with it and use it. If someone tried to build my FE Javascript project with Make, I would not use it. If they used yarn instead of npm that would be a Gradle vs. Maven situation as above, so either's fine if there's nothing yet. If there's a set of bash scripts that are perfectly adequate to build the project you have, fine, why use Make? And let me tell you from experience, conventions are great but don't always work, i.e. no $CC and $DESTDIR are definitely not something every user of Make does appropriately. I've had to add that to a few back in the day. You install like you're used to with DESTDIR only to find that it just installed itself into your system. You swear, fix it and learn to _always_ check a newly downloaded project for whether they actually have the 'standard' features implemented before you build something. Contrast that with many of the newer build and packaging tools, that basically take this choice away from the user, which is a great thing if you ask me. Sure you have to get over the "but I want to do it my way" defiance reaction but in the end it is awesome when each new project you come to you do _not_ have to check and learn how exactly that project does things because every Maven project has its stuff in the same place (unless someone re-configured it, which unfortunately does happen). But maven is bad nowadays, coz it uses XML :(
pmiller2 6y ago
Indeed, crazy dev setup is definitely like a code smell. I remember at one place, it took me 3 weeks to get to the point where I could merge my first PR. Another place I was at, they handed me a laptop that was already set up to run the code, and all I had to do was set up my own editor. Guess which place I was more productive.
- makapuf 6y ago
  I find that very nice: last arrived on a project (on a similar role) will setup a working environment for the next one to start with. It fresh enough that you remember it, and you could even find interesting to clean up a little.
  - pmiller2 6y ago
    That's not a half bad idea if the setup is any more complicated than "clone these repos and run the setup scripts."

berkes 6y ago

I recently joined a new team and codebase. There was no 'getting started', no docs. I was left on my own. So I muddled through. And documented everything in Makefiles. Not readme, but working code. Now `make clean` `make install` etc, all run, deploy, install, clean etc the project. A great way to learn. But unfortunately worthless to others in the team, as they all were entrenched in their own ways and setups. I just added a sixth' way of 'working with the codebase'. I'm no to sure if it is the team, me, or Make, but I certainly won't spend such time a next new codebase arrives. (I do add makefiles on each of my private and opensource projects though, and will keep doing that)

gonzo41 6y ago
> they all were entrenched in their own ways and setups. I consider this a bad behavior. If people espouse the benefits of CI/CD and cattle over pets. Then I firmly believe that thinking needs to make it's way to the dev environment. And what you did isn't worthless, the next person get's to go quicker and spend effort on features that make money.
- berkes 6y ago
  > I consider this a bad behavior. Part of it is probably that I fixed something that wasn't broken for them personally. I understand than when a new person joins and starts telling you that you should now start using this "new", "Makefile" thing, you'd probably be annoyed and get back to work instead.
aidos 6y ago
Your team sounds a little broken. If a new starter came in and did that for our project, I’d be really pleased. Once you have that stuff setup, and you’re doing “day to day” coding, it’s hard to find time to go back and sort that stuff out. It’s something a new starter can take on that ultimately gives good long term outcomes.
- gabereiser 6y ago
  Exactly. Sounds like rot has settled in and there’s a serious lack of empathy for coworkers (who have to wade through that tall grass like those before did). Cut the grass. Better yet, pave it. Docker compose up your dev environment. Make it so going from clone->pr is as quick and painless as possible.
adriancr 6y ago
What I've done in the past and worked is as follows - learn from others what they are doing and why. It may look inefficient but there may be good reasons. - document everything / make sure your understanding is correct and others can follow your documentation and use the old flow. - start automating and improving while keeping existing things that worked still there. Doing things this way I was able to improve processes for very bureaucratic companies and have had people appreciate and put in their time to help once they started using.
reidjs 6y ago
What is the benefit of makefiles over bash scripts?
- nemetroid 6y ago
  A Bash script is a linearization of the dependency graph, a Makefile is a description of the graph itself.
- muskox2 6y ago
  - Make is a standard utility, so anyone that has used make before will know what 'make', 'make clean', etc will do without having to read any documentation. - Make has the ability built-in to only run certain commands based on the files that have changed, which can be handy. - Makefiles usually have a lot of handy variables for configuring the project like $CC or $DESTDIR. While you could have these in a bash script as well, there's a standard convention for variables in Make[1]. In my experience, Makefiles are usually better documented and follow more conventions than scripts. There are of course many exceptions to every rule. Make files are very similar to bash scripts, and while I would prefer a Makefile any day, it's really a matter of preference. [1]: https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html https://www.gnu.org/prep/standards/html_node/Makefile-Conven...
  - tharkun__ 6y ago
    I think we also need to be careful. The OP on this thread did not specify what kind of project. Make may be completely appropriate. It might also not be and just what they are used to. The proverbial hammer. If someone came in and tried to build my Java project with Make, I would definitely call them crazy and not use it either. If someone came to my Java project and tried to put Gradle on it to build it, I might also not use it but at least its appropriate for the language and if everyone on the team/project was OK with it, I would probably be OK with it and use it. If someone tried to build my FE Javascript project with Make, I would not use it. If they used yarn instead of npm that would be a Gradle vs. Maven situation as above, so either's fine if there's nothing yet. If there's a set of bash scripts that are perfectly adequate to build the project you have, fine, why use Make? And let me tell you from experience, conventions are great but don't always work, i.e. no $CC and $DESTDIR are definitely not something every user of Make does appropriately. I've had to add that to a few back in the day. You install like you're used to with DESTDIR only to find that it just installed itself into your system. You swear, fix it and learn to _always_ check a newly downloaded project for whether they actually have the 'standard' features implemented before you build something. Contrast that with many of the newer build and packaging tools, that basically take this choice away from the user, which is a great thing if you ask me. Sure you have to get over the "but I want to do it my way" defiance reaction but in the end it is awesome when each new project you come to you do _not_ have to check and learn how exactly that project does things because every Maven project has its stuff in the same place (unless someone re-configured it, which unfortunately does happen). But maven is bad nowadays, coz it uses XML :(

pmiller2 6y ago

Indeed, crazy dev setup is definitely like a code smell. I remember at one place, it took me 3 weeks to get to the point where I could merge my first PR. Another place I was at, they handed me a laptop that was already set up to run the code, and all I had to do was set up my own editor. Guess which place I was more productive.

makapuf 6y ago
I find that very nice: last arrived on a project (on a similar role) will setup a working environment for the next one to start with. It fresh enough that you remember it, and you could even find interesting to clean up a little.
- pmiller2 6y ago
  That's not a half bad idea if the setup is any more complicated than "clone these repos and run the setup scripts."