Dear Devs,
How much are you interested to work on an ASP.Net or .NET Core project? How do you see Microsoft certifications as a solutions developer?
Cheers!
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Why every startup should be built on open-source... 🤔🤔
Nevo David -
I hold back on job applications, compensating with tech dev blogging and ongoing side projects – this ain't effective innit?
Retiago Drago -
Open Source ABCs: Quality Assurance
BekahHW -
What's Your Ideal Coding Environment?
dev.to staff -
Top comments (15)
With the open-sourcing of the runtime and framework and advent of kestrel, there literally could not be a better time to be getting into, or continuing to hone your skills in the .NET stack.
Building your solution today in .NET Core means potting yourself a strongly typed environment, a blazing fast web server in kestrel for ASP.NET projects, a vibrant open-source community which currently leads GitHub in # of open projects and a ridiculously well-planned and mature language in C#.
Bottom line, Microsoft’s .NET Core offering is ridiculously awesome and well worth a try. Gone are the days of the clunky .NET Framework.
Ditto! I've liked and worked with C# for a while now but with .NET Core, it makes it more interesting than ever to be a .NET Developer.
Open source, cross-platform and now better performance than ever, what is not to love?
The most encouraging feedback ever. Many thanks for your reply, I would be very valuable for me.
We use Microsoft technologies at work. Initially for historical reasons. But I still choose to use the platform because of F# and a decent ecosystem (libraries, IDE, etc).
We have started to switch over to .NET Core, and have it in production. The tech is in a decent state and with Core they are finally offering more flexible deployment options (linux, native binaries, etc). With the natural consequence being that the configuration is different and a little more complex vs Framework.
I am only interested in ASP.NET up to Kestrel in the stack. The frameworks that are higher on the stack like MVC are of no interest to me. (I have previous experience with most of the ASP.NET frameworks since .NET launched -- e.g. WebForms, MVC, WCF, Web API, etc.) Newer apps/services that we develop are by and large framework-less. However, I believe our approach is different from most Microsoft shops. And MVC knowledge is generally in demand if you use ASP.NET Core.
The only tech-related certifications I have seen which directly correlate to capability and therefore salary are Cisco certs (which is networking, not dev). It doesn't hurt to have Microsoft certs if you want to be in the Microsoft stack. But in my view the amount it helps is marginal at best. Your effort would probably be better spent setting up a github repo as a practiced example to put on your resume.
This is interesting. I'll give certification the second priority. Let me collect more feedback. Thank you very much.
"Newer apps/services that we develop are by and large framework-less." - I would LOVE to hear more about this.
I've been thinking through a blog post on this exact topic for APIs. The main challenge has been teasing out what is required for framework-less from the rest of the design principles we used. Here is a rough overview. Feel free to comment or ask more questions.
Backend
For us, I think the primary factor to become framework-less has been the pragmatic use of functional programming. No more inheritance, interfaces, overrides, attributes, etc. Just types and functions on those types, and everything is easy to compose together. Here is a humorous video on these "functional design patterns". Functional programming informs the other things I mention below.
I had to write a few small libraries myself where the alternatives already in the ecosystem were frameworky. For example, HTTP request filtering/routing (7 source files), SQL (7 source files), and validation (4 source files). The theme of these libraries are: instead of having to inherit and override preset methods, provide common functions that users can chain together. And allow the user to add their own functions for cases not covered.
I believe another important factor is the pervasive use of messaging. Primarily that our business logic only returns decision events rather than actually performing the IO themselves. Subsequent steps in processing the request can simply map the decision events to whatever IO is appropriate (SQL statements, email, etc), even ones we think of later. Whereas a framework usually does not make it easy to plug in new IO integrations. And IO in business logic just makes that logic hard to test and compose with other code.
Front-end
This one is a bit easier, because there already exist some "platforms" that tie most everything together into a unified solution. Elm is the most obvious example. The most "frameworky" bit of it is the JS interop using ports. Otherwise, Elm prescribes an application structure (Model/Msg types and View/Update functions - aka MVU) and that's it. Most everything you do after that is your own code to solve your own problem. It uses a virtual DOM library to render HTML, similar to React's. It also provides some other libraries like HTTP, Regex, etc. Even if you ultimately choose another MVU platform, Elm is a great teaching tool. We're using it in production currently, but evaluating other options.
Note that MVU is designed to handle different circumstances from a back-end API. MVU is designed to collect user inputs that may be haphazard or never come at all. Whereas request/response APIs usually expect to execute a use case in a consistent and sequential way. So using MVU for APIs is paying overhead for flexibility that will not be used. However, MVU is a lovely pattern for Process Managers.
I think my mouth was open the entire time I read that just now ...
interest in Microsoft technologies has declined over the years. Here's a stackoverflow trends comparing it to other languages like Java and Javascript
If you plan to work in the corporate IT development arena, the Microsoft technologies are where the jobs are. If you want to work for cool tech start-ups and such, then you won't find it as much. If you are an older developer, like me, knowledge of the Microsoft development technologies will allow you to keep working and making a good income when the "cool" tech companies won't give you the time of day.
I don't see the certifications as valuable. I'm a lot more interested in the projects you've done and how well you can describe them rather than language trivia tests you can pass.
I've spent my whole career as a LAMP stack dev (well except for those few months with VBScript and ASP Classic).
But from the outside it all seems cool and under Satya Nadella I love the direction MS has gone in and I'm tempted to give them more attention. I've played with .NET core a little back in release client days, but not much since then.
I still am not a fan of Windows as a desktop OS or server OS. If I were to do .NET Core it would still be on Linux for me. Great that it can be!
0
Zero counts. Thank you for the feedback.
I'd say I'm interested and always on the lookout. A platform with the backing of a tech giant like Microsoft is nothing to scoff at. I like C# as a language, but Linux support for .NET still feels like working on a second-class citizen operating system. I guess we'll see!
I like the MS stack. I would be happy to work in any stack however here in Indiana, Microsoft technologies seem to be king. I pick one stack and focus on that only because learning new stacks would take away too much attention and energy from my real love - software development research. The research I do could be done with any stack. And I intend to port it to the others once I have gotten far enough along.