Profile picture of David Paul McQuiggin
David Paul McQuiggin
[Remote] .NET Lead Engineer | Solution Architect | CTO | Azure | Data | AI
Follow me
Generated by linktime
May 22, 2017
I share a degree of unease too. Starting from the initial opening of Visual Studio 2017, there was a moment of confusion - how to I apply my usual colour scheme, which is so carefully crafted to give me a good experience? Not available yet (there is a work around with a hacked' version of the Vs 2015 Color Theme Editor). An IDE that cannot be themed? In 2017? Next was the hamfisted way of working with .csproj files. Major step back from Project.json, which was actually intuitive, and for web devs, worked so well with json-as-a-standard. Working with NuGet is also jarring, as mentioned in the article - it's counter-intuitive that you cannot right click the NuGet node to manage Nuget references, but must right-click the generic References node. Restoring of packages seems haphazard, and I often have to close and reopen solutions to get intellisense to stop reporting errors, or use the command line and do a dotnet restore. But, there are plusses; detecting slow extensions, Live Unit Testing (although I do still use NCrunch...), fast project loading is a move in the right direction. The installer, and reduced footprint of installations. A seemingly rapid update cycle (some would argue a beta product needs that!) https://lnkd.in/en-97kx
Stay updated
Subscribe to receive my future LinkedIn posts in your mailbox.

By clicking "Subscribe", you agree to receive emails from linktime.co.
You can unsubscribe at any time.

May 22, 2017
Sunday evening take: One thing I dislike about working in software development over all these years, is that so much time is spent arguing over software ideology, as if there is an absolute perfection or one true way. e.g. SOLID is guidance, to be taken under consideration, applicable in some scenarios and not in others, it is not the word of god / the one true way. Developers spend too much time fighting over their interpretation of what is basically other people's opinions, something they have read very recently in a blog or seen in a course, as if it is some sort of divine inspiration. They then point-score as to who has the most perfect understanding of the opinion of someone who wrote a book about their own experience, but has no idea of the realities of the project you are now working on. I have been in so many code reviews, where developers were obsessed with arguing over the minutiae of a particular line of code and how it does not meet framework guidelines / latest C# language syntax / a specific pattern in a book, that they completely missed that it did not actually meet the business requirements. Guidance such as SOLID, Clean Coding, DDD etc. is fine if you treat it in the same way as 'look both ways before crossing the road', but not 'you must spend 10 seconds when looking left, and no more than 1 second later, look right for 13 seconds, or a successful crossing of the road will be deemed inadmissible' Be pragmatic instead of dogmatic, is the best advice I can give, after 32 years of building systems.
21 comments
April 3, 2022