On 25.05.17 01:22, Craig Sanders via luv-main wrote: > I just saw Erik's reply to this, hadn't noticed your original post until > now. > > On Fri, May 19, 2017 at 07:22:20AM +1000, Piers Rowan wrote: > > We have grown quite a bit and having each dev running their pet dev > > environment seems eclectic and difficult to manage (aka manage down > > when you need to help a colleague and it take you 5 minutes to work > > out how their IDE / screen is working). > > Іf you want an absolutely certain way to totally destroy a developer's > productivity, force them to use your (or someone else's) preferred IDE. > or worse, an IDE chosen by committee/consensus.
+100. In three decades, I never asked the developers what their preferred edit environment might be, even permitting editing on Mac/MS, so long as *nix line endings and space-substituted tabs were used. (The former to avoid 100% deltas on code check-in, and the latter to avoid indenting appearing to change when someone had different tabstops.) > As long as they're committing their changes regularly to the version > control system, I had the developers working on individual branches, then performed all main branch commits myself, after checking that there were no CRLFs or other nonsense, and that it compiled. Adding a useful version tag and management-relevant commit message is also best done with an overview. > and following the required coding style, As for "required", I let the team drive the coding style requirement, as my only needs were consistency and readability. Since the team had set the style standard (mostly pilfered clauses), it was self-enforcing. Any cowboy was soon lassoed by annoyed colleagues. > let each of them use what they want. Otherwise you're forcing them to > throw away years of experience with their tools. Also, they're almost > certainly going to keep using their own preferred tools at home, so > they'll suffer a jarring context switch every day when they come in to > work. Yes, let code generation be their expertise, and simplify/offload version control and code build management, to avoid productivity bottlenecks. I found it useful to provide makefile support to the team, so they didn't need to spend time climbing that learning curve. Then they really didn't need to know much about the GNU toolchain either, as I always built the cross-compiler before staring the project, and the makefile handles the details. > Nominate a preferred or supported IDE if you want but don't force > everyone to use it. Yes, by supporting what you put in place at the start of each project, developers are empowered to focus on productive code generation. > If you're using git for version control (and why wouldn't you?), > gitlab is a pretty good tool for running your own github-like source > repository, issue/task tracker, developer wiki, That's useful. I just created a plain text howto file at the top of the project directory tree, i.e. one level above src/ and design/, and tuned directory and file permissions to control who could edit what. A script generated the tuned project tree before the team was assembled. If gitlab does all that and more, then it saves the DIY effort. > built-in CI tools (e.g. you can configure it to automatically try to > compile the software on every commit and report the outcome to the > developer), and more. Maybe things are different in the embedded world, but I can't remember a developer submitting code which didn't build - that would be a professional embarrassment never lived down. And the makefile could readily support a "make commit", to automate a pre-commit build. I have to admit to relying on healthy paranoia to ensure I checked that it built, before the commit. While I'm a dinosaur who uses cvs for local version control, that's only due to long familiarity, and I'd use git or mercurial if still professionally active. (Infinitely better to have that on the CV, too.) Erik -- Programs must be written for people to read, and only incidentally for machines to execute. - Abelson and Sussman _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
