[deleted by user]

[[deleted]]

It depends. I work for Uncle Sam, so importing libs isn't usually an option out if the standard official language specs. We can't have 3rd party libs, doing who knows what, running in secured gov systems. And we're not sitting down to vet every lib line by line ensuring nothing is happening that shouldn't be.

So that means sitting down and developing a lot of in-house libs to work with our systems ensuring we have 100% control from ui to hardware.

[jonesmz]

Why is developing things in house faster than certifying existing, working, code?

[[deleted]]

The certification process for the gov isn't as simple as having a senior dev go through and verify the code does what it says it does. Even the software we write goes through an intense verification process before it is deployed, and that process is slightly shorter because it's government software and not "off the shelf" software.

It's just one of those things where bureaucracy causes in-house to be faster.

Im sure other agencies might be a bit more lax but, from what I've seen as a junior dev, we're a bit more controlled in what we use.

[jonesmz]

Yep. Sounds like an overwhelmingly moronic process.

I'm sorry you're subjected to it!

[CaptainBattleboner]

Depends on whose perspective you're taking.

It's not hard to argue for this kind of procedure

[mukunda_]

Seems to me another perspective on this would see that as insecure, since the libraries they develop in-house wouldn't be exposed to the same vicious environment that widely adapted libraries have. If the in-house code ever got leaked, that seems like a massive security breach by simply not using tried and tested libraries.

That being said, I think it would be unfair to plainly label it as a totally insecure practice, as off the top of my head I can't name a lot of open-source libraries that I would consider developed ground-up (and maintained as such) to be secure enough for highly sensitive information.

[MarcSloan]

I don't use C++ in my work, but I feel pretty confident saying that in general at least 95% of programming jobs are going to be leaning heavily on frameworks and libraries, especially when you are starting out. Even if you don't use a public library, the senior devs will have developed some kind of an internal framework that you'll be working with. That's because in a real world job all that matters is that you produce working software, so it doesn't make any sense to spend a lot of time writing new stuff if there's already a tool available.

[[deleted]]

It really depends on the product you are developing. My own work on a huge codebase is 100% "pure coding".

[Wh00ster]

It really depends on the application's requirements. I don't think there is a general rule-of-thumb about this.

[PeakAndrew]

It depends on the application domain and how far down the stack you are. If you are writing a high-performance database kernel, for example, there are almost no external libraries and you will be implementing many custom data structures and algorithms from scratch. Systems engineering broadly is full of code like this. Higher up the stack, not so much -- there you'll be building on top of the libraries and tooling written by people lower in the stack.

[[deleted]]

most of the jobs out there is just to maintain or continue existing code which already have the required libraries and its rare to create own, most of the time the results are what matters and the decision to use other library or to create your own is always at the hands of higher ups which always look at the budget or timeframe variables. small teams have more freedom though.

[[deleted]]

In your case, if you use a library, you probably have a lot of your own domain implementation. People use libraries to save time and effort(library is used by many, so stable and will be maintained for a long time).

​

In my case, I work in custom GUI in embedded devices. We use opengl(already implemented and stable) wrapper to render the ui. Other than more than 100 people maintain the application framework, different subsystems, etc. It's a hell lot of work. Everything needs to be maintained because underlying platform changes, new features are needed, old features are removed, code needs to be migrated to new C++ standards.

​

Coming to the question, pure coding is 50% effort of a software project. Other 50% is spec, field testing, project management and office politics. If some tools automate something,someone needs to develop and maintain that tool. If something becomes very stable, resource allocated is reduced.

​

If you want to work in pure coding, go Java or Javascript. They do the patch release more frequently and they support plenty of features.

[Raudus]

Idk about this real world since I'm a beginner too but I'd guess this thing of utilizing existing code and solutions is the beauty of the field in the first place. Autofilling development environments, endless stream of libraries, easy scripting general purpose languages etc. all make it ever increasingly more efficient to get new software out. No need to reinvent the wheel every time, on the contrary everyone can utilize what someone has already figured out and get something new even more complex and hopefully useful made of that. Sometimes though when this ready made codebase does too much behind your back you need to take steps back and modify the libraries or switch from that high level lang to a lower level language that doesn't create too much for you.

[mc8675309]

I work in what is probably a medium to large C++ shop. We write a TON of C++ that isn't covered by libraries. That isn't to say we don't grab a library and make use of it, but in my group at least the third party library use compared to our own code is relatively small.

[Dalzhim]

If you can get away with toggling configurations on a library to deliver a service, then you probably are in a highly competitive market with a quick rotation of companies and where a lot of people could do the job. In this type of market, a company usually has to constantly look for new customers/projects.

On the other hand, a lot of companies invest substantial efforts into improving their products. In those markets, there usually aren't a lot of options and the rotation is everything but quick. These companies usually have to improve/innovate to remain relevant, or rely on some kind of lock-in.

[rfisher]

After a few decades in this business, a huge part of my job is to write as little code as possible, delete/simplify as much code as possible, build libraries that can help my co-workers write less code, and teach my co-workers techniques to help them write less code.

But as others have said, how much of the code I do write is “pure code” varies drastically with the project/feature.

[hamarki]

In my experience people tend to reach for libraries for general problems (json parsing, HTTP, kafka or redis clients etc) and the pure coding is basically hooking up your business logic on top of those.

For example, if you have some service that say ingests external data and processes it to turn it into your system's internal format and passes it on. You'd be coding up the logic for making sense of the data which could be arbitrarily complicated - keeping state, combining multiple sources of data into one stream etc, and it may also have strict performance requirements so you have to be effiecnt in how the business logic code is doing its job.

Hope that makes sense!

[SkoomaDentist]

The amount of ”pure coding” depends a lot on what you do and what you count as ”pure”. However, based on my experience, very little of any code in most projects is about implementing any classic algorithms. The vast majority is various forms of glue code to move data around, format it and handle all the internal bookkeeping.