I love all the points here. I think the big question is, is it possible to have a programming job now adays where more time is spent on writing code rather than fighting with external libraries, dependencies, and frameworks? In my personal experience so far, I tend to spend a lot more time on the former when I do native development and way too much on the latter in web development. However, my experience is quite small so I wanted to hear other experiences on this as well.
At the same time, I know when you show up at any software job, unless its a startup, it's going to have a codebase already so I suppose you could say that is equivalent to "fighting with external dependencies" in some ways.
At the same time, I know when you show up at any software job, unless its a startup, it's going to have a codebase already so I suppose you could say that is equivalent to "fighting with external dependencies" in some ways.
Todd
I love all the points here. I think the big question is, is it possible to have a programming job now adays where more time is spent on writing code rather than fighting with external libraries, dependencies, and frameworks? In my personal experience so far, I tend to spend a lot more time on the former when I do native development and way too much on the latter in web development. However, my experience is quite small so I wanted to hear other experiences on this as well.
At the same time, I know when you show up at any software job, unless its a startup, it's going to have a codebase already so I suppose you could say that is equivalent to "fighting with external dependencies" in some ways.
The path of least resistance for what you're wanting to do is one of two routes:
1) Get in on the ground floor of a software company where you can make impactful, long-term decisions on the infrastructure that's put into place.
or 2) Don't work for a software company. Work for one of the thousands of small/medium-sized businesses out there that employee a small group of software developers.
I've shot for #2 throughout my career, because #1 comes with stability concerns and I have a family to provide for. With small/medium-sized businesses usually an infrastructure is already in place, however, it's not going to change as rapidly as software development does in the software industry. It's not unusual to still see 20 year old IBM AS/400 mainframes out there still powering medium-sized industrial businesses with a couple of old guys in the basement pumping out RPG2 and COBOL code.
With these small/medium-sized businesses, their infrastructure doesn't change often. They stick to stability instead of having the latest and greatest - which means you usually have to fight less with dependencies and more with maintaining legacy code. However, this does give you the ability to write solutions from scratch and slowly cut away at the infrastructure that was put into place before you got there.
Also, they pay REALLY well.
Edited by 0x2329
on
I use C#/F# at work, and for many of my side projects as well. I actually like them both a lot. Generics in .NET are very nice.
I just take care to make sure performance is good, which allows my day job website to run on very inexpensive azure app services. One of my next projects will be to improve database performance and reduce server side CPU usage by replacing Entity Framework with F# SQLCommandProvider.
You should look into it. On the one hand it is some very high tech stuff, on the other hand it lets you write SQL by hand, so there is no performance overhead at runtime. A little demo gif, where you can see how you get an IDE-time error message due to a typo in the query. Fix it, then you get types created automagically for the data the query returns:
http://imgur.com/NOAS5yY
The biggest CPU hogs on the server when I profile these days, due to efforts to reduce cpu usage everywhere else, is entity framework, so switching to this will eliminate that. A strange mix of going more abstract and less at the same time.
I just take care to make sure performance is good, which allows my day job website to run on very inexpensive azure app services. One of my next projects will be to improve database performance and reduce server side CPU usage by replacing Entity Framework with F# SQLCommandProvider.
You should look into it. On the one hand it is some very high tech stuff, on the other hand it lets you write SQL by hand, so there is no performance overhead at runtime. A little demo gif, where you can see how you get an IDE-time error message due to a typo in the query. Fix it, then you get types created automagically for the data the query returns:
http://imgur.com/NOAS5yY
The biggest CPU hogs on the server when I profile these days, due to efforts to reduce cpu usage everywhere else, is entity framework, so switching to this will eliminate that. A strange mix of going more abstract and less at the same time.
This is an interesting question. As a gameplay programmer, I work within existing game engines (currently UE4), which is in itself a massive dependency, and shapes everything I do. Therefore I wouldn't tend to consider my work Handmade in any meaningful way. The Unreal Engine is interesting in itself when considered from a Handmade perspective. On the one hand, it is very far from being Handmade. It has a pretty extreme OO design, include the kind of deep inheritance hierarchies that even OO proponents tend to try and avoid these days, it has numerous dependencies, a largely compulsory garbage collector, and of course is in itself a massive abstraction layer keeping you away from the hardware. However on the other hand, it is a codebase that is clearly cared for and maintained, the code is almost entirely provided meaning that nothing is truly a black box and off limits, and the dependencies are very sanely managed (either the dependencies are simply build along with everything else or the correct binaries are provided).
As for the second question about the amount of time spent programming, I don't have sufficient experience to really say, beyond saying that if you had told my student self how much code I would write a day once I got a job, I would have laughed. Without exaggeration, I think I probably wrote an order of magnitude more code most days as a student than I do now. However it's worth saying that this isn't (entirely) because of time spent wrangling with libraries, dependencies and frameworks. It's also all the other stuff that comes with the world of work too, like working out what needs to actually be done, who to talk to, offering more general support for other team-members which doesn't really involve writing code yourself, syncing builds, context switching between tasks etc.
Even outside my work though, I would say that only the minority of my own code is really written in a Handmade style. When I'm making simple standalone widgets, I will sometimes follow a Handmade approach, but if heavy text processing is involved for example, or an elaborate GUI, and performance isn't a major issue, I'm just as likely to throw together a script in Python. Even the game I'm working on currently, which I started long before I discovered this community, is based on a cross platform C++ game library rather than being developed from scratch. I'm definitely looking for more ways to experiment with a Handmade development style though.
As for the second question about the amount of time spent programming, I don't have sufficient experience to really say, beyond saying that if you had told my student self how much code I would write a day once I got a job, I would have laughed. Without exaggeration, I think I probably wrote an order of magnitude more code most days as a student than I do now. However it's worth saying that this isn't (entirely) because of time spent wrangling with libraries, dependencies and frameworks. It's also all the other stuff that comes with the world of work too, like working out what needs to actually be done, who to talk to, offering more general support for other team-members which doesn't really involve writing code yourself, syncing builds, context switching between tasks etc.
Even outside my work though, I would say that only the minority of my own code is really written in a Handmade style. When I'm making simple standalone widgets, I will sometimes follow a Handmade approach, but if heavy text processing is involved for example, or an elaborate GUI, and performance isn't a major issue, I'm just as likely to throw together a script in Python. Even the game I'm working on currently, which I started long before I discovered this community, is based on a cross platform C++ game library rather than being developed from scratch. I'm definitely looking for more ways to experiment with a Handmade development style though.
MandleBro
One of my next projects will be to improve database performance and reduce server side CPU usage by replacing Entity Framework with F# SQLCommandProvider.
You should look into it. On the one hand it is some very high tech stuff, on the other hand it lets you write SQL by hand, so there is no performance overhead at runtime. A little demo gif, where you can see how you get an IDE-time error message due to a typo in the query. Fix it, then you get types created automagically for the data the query returns:
http://imgur.com/NOAS5yY
Thanks man. Yeah C# still has a special place in my heart and is still very useful as it was my first language that I learned in-depth. I rag on it sometimes, mostly because what I've heard from Casey and Jeff from RAD/HH, but C# does have its place for quite a lot these days. My personal take is this: If I do want to use an OOP language, C# is the best I can get, and the cost of having to "orient" my code towards objects just needs to be weighed against what the end-goal is. For example, you can get a working app that does more complex stuff up and running a lot faster in C# where extreme performance optimization is not needed, whereas I find C to be more fun and more rewarding, but it's definitely not a "get it up quick" type of situation. Some people get all up i in arms about some of the rants Casey goes on, but the fact is, he's a game programmer and has always been a game programmer, and the real-timeness of games certainly comes with a higher demand for performance/optimization than web applications. That said, of course this is not a rule and personally I wished there was more focus on performance in modern web frameworks.
I appreciate the suggestion, I've been looking for alternatives to Entity Framework. The thing that kills me most about this stuff as I mentioned prior is that I tend to spend countless hours fighting with stuff like Unity DI framework, Entity Framework, Owin, Identity/OAuth, etc... I feel like it's more justified at least with OAuth and Identity because let's be real, everyone knows to not try to roll your own encryption service unless you're a security guy, but a lot of the other dependencies as kinda iffy. That said, I haven't much tried .NET Core yet, and I know that it is going to be a lot more modular and light-weight. Have you any experience with ASP.NET Core?
Honestly, my chief complaint with most the C# web dev stuff has nothing to do with C#, but I just feel like it's too bloated with ridiculous jargon like:
1 2 3 | MyServiceProvider<IProvider,Provider> serviceProvider = new MyServiceProvider<IProvider,Provider>(appSettings.Create(new Application()) blah blah. serviceProvider.WipeMyFloor(appSettings.Owin.Get.Current.Floor); |
it's like, why does that need to be so cryptic, ya know? What it's doing is so simple, but the OOP like jargon from Microsoft is very "Microsofty" and makes it way overly complicated. Alright, I'm ranting. XD
Edited by Todd
on
I haven't done anything with .NET core yet.
Our project at work is moving towards using react on the front end, and webapi2 on the back end. So the razor views mostly go away, C# just provides endpoints that return json or xml for the front end to consume. I think it will be nicer. .NET core won't change much, though we will have to redo our authentication which is a pain.
Our project at work is moving towards using react on the front end, and webapi2 on the back end. So the razor views mostly go away, C# just provides endpoints that return json or xml for the front end to consume. I think it will be nicer. .NET core won't change much, though we will have to redo our authentication which is a pain.
MandleBro
I haven't done anything with .NET core yet.
Our project at work is moving towards using react on the front end, and webapi2 on the back end. So the razor views mostly go away, C# just provides endpoints that return json or xml for the front end to consume. I think it will be nicer. .NET core won't change much, though we will have to redo our authentication which is a pain.
Funny you say that because that is literally 100% what I'm doing right now. Had to take an ASP.NET MVC project and rewrite it in Web API 2 (ok, I didn't HAVE to re-write it but I found it actually easier to just separate it out as a separate "solution" and pretty much start from scratch because blending MVC auth with Web API 2 auth was a real beast) and right now I'm dealing with the OAuth and JWT stuff which as you said, is a pain. I got the auth server and token system up last night and have been testing it. It just seems so overly complicated for what it's doing. Like Casey has said on Handmade Hero, this is a god damn text delivery service at the end of the day... Why is it so complicated! Lol. Like what is this garbage:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
{
context.Validated();
return Task.FromResult<object>(null);
}
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
var allowedOrigin = "*";
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { allowedOrigin });
var userManager = context.OwinContext.GetUserManager<BusinessAccountManager>();
BusinessAccount user = await userManager.FindAsync(context.UserName, context.Password);
|
Such poopy convoluted object names IMO. "OAuthGrantResourceOwnerCredentialsContext" give me a break!
Edited by Todd
on
OH GOSH THIS IS SO CLASSIC: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
If you haven't seen that, you're gonna love the source code!
If you haven't seen that, you're gonna love the source code!
Lucas I know what you mean. Frankly, I'm getting pretty sick of installing all of this bullshit doing web development. All I seem to do is install new tools and dependencies and fight with them all day long. Not fun at all. When I program in C I'm usually programming most of the time.
It's like oh wait, this project uses SQL Server + .NET Core in Visual Studio Code... That project uses MySQL + .NET Core in Visual Studio 2015 with Dapper and 15 "packages," and the 3rd project uses ASP.NET MVC5 with Web API 2 and Entity Framework... Oh, with xyz testing framework ofc.
I've literally spent the past day or two "setting up" to do actual programming that I could have done by now if the project was using my usual toolset. Good God.
It's like oh wait, this project uses SQL Server + .NET Core in Visual Studio Code... That project uses MySQL + .NET Core in Visual Studio 2015 with Dapper and 15 "packages," and the 3rd project uses ASP.NET MVC5 with Web API 2 and Entity Framework... Oh, with xyz testing framework ofc.
I've literally spent the past day or two "setting up" to do actual programming that I could have done by now if the project was using my usual toolset. Good God.
Edited by Todd
on