Rob Mile's c# programming Yellow Book http://www.csharpcourse.com/ was a nice read

&& must be ||

Or even better make the code clean so it doesn't even need comments most of the time. Paper documentation tends to grow out of sync with the actual code implementation pretty fast. So readable self-explanatory code is the way to go in the long run.

There is a console UI project on GitHub https://github.com/migueldeicaza/...

I've been planning to play with it some day :)

But I'm sure there are Linux specific UI project also.

Also, did you see those new cool toys running .Net in the browser? Client side using .Net through web assembly?

They use mono for it because the Roslyn compiler itself can't be compiled to webassembly if I understand correctly.

So there still is a place for mono for the time being :)

@tsirpos
It's planned for dotnet core 3!
https://blogs.msdn.microsoft.com/do...

It does *not* make it cross platform though. It's just a way to add new features/improvements to windows forms without breaking backwards compatibility with .Net Framework.

Cross platform UI's are hard to get right. I haven't seen any successful implementation that didn't had to do compromises to get it right. The hard part is to make it look native the the platform running it.

I started with GoF during my bachelor's degree. It was one of the best courses that I took, but now that I look back on it, I think I'd rather would've read Uncle Bob's work before GoF. I'm taking the Clean Coders Video course now. I would recommend it!

I'm also planning on reading:
1. Martin Fowler - Refactoring
2. Michael Feathers - Working effectively with legacy code
3. Beck, Kent (1999). XP Explained

Not sure about the order though.
Maybe I'll switch between them and read them all at once :)

@djsumdog If you can't keep up with the pace of the sprints and feel like you need to rest, then possibly your team is not practicing Scrum correctly.

Quoting one of the Agile Manifesto's principles: (yes I'm that kind of guy)
"The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely."

So try to seek a pace that provides both (technical) quality and business value in a way that you don't need to rest.

Often going "slower" and taking the time you know the job demands, will result in fewer bugs and less technical debt. As a result you will go faster in the long run (and often surprisingly also in the short run).

But the bad news is that this is very hard to get to. You need the whole team to have the same mindset and take a stance.

Try discussing it in your next retrospective.

@CozyPlanes SMB ;) smtp is used for email.

http://wiki.c2.com//...

@bkrem or Dutch ;)

It seems that the owner of the twitter handle has created a new handle to tackle this problem :) https://twitter.com/undefined