|
Depends on the size of the company and the size of the code base. Also, depends on the experience of the engineer.
If it's a small project and a very experienced person, they can usually hit the ground running-ish. As in, that's goal, but there was always quirks in every business the dev needs context for. But, provided that is met then he/she can be off in a couple weeks tops - if their very familiar with the tech being used.
If he/she is a senior but they're not familiar with the tech, even a smaller project can take time.
If it's a large code base with 40 projects and took 50 years to develop, expecting a senior to master that in a couple weeks is absurd.
If all things are perfect but they're stuck in meetings, that takes time.
List goes on. A lot of a variables at play.
Jeremy Falcon
|
|
|
|
|
It really depends. For me I do embedded and I'm used to doing the software on my own. I'm pretty quick based on my observation and that of my clients, but I'd be slower if I wasn't doing embedded or if I had to deal with other people's code.
I have external limiting factors on how much work I can take on, but people around here know I can produce at volume. I have a terrible reputation. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
In a case like yours you probably have to build by yourself everything your program might require, containers, hash maps etc. Third party libraries for projects like yours are probably rare.
|
|
|
|
|
Indeed. I have built up an entire ecosystem for embedded over the past several years.
It doesn't help that I can't use The STL in C++ because it's often incomplete or non-standard, or otherwise is irresponsible in how it uses the heap.
Oh and everything basically needs to be cross platform.
I have my own cross platform graphics library that does SVG, PNG, JPG, TrueType, X11 colors, alpha blending, etc.
I have my own UI/UX library that builds on it.
I have drivers for many different devices that work on several platforms.
I have simple hash maps and such as you say.
I've produced a lot of code. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
It's impossible to answer.
In general, one or more programmers are in charge of a section of the code (graphics, database, UI, business logic ... )
Depending on the size of the software, a coder can be in charge of more things,
Senior will take care of the most complex things, architecture and/or software design; junior will do simpler things; smaller changes, simple new features and learn from that.
In my previous job, after 20 years, I knew most of the software except (advanced) 3D graphics and maths stuff. I needed, I could probably go in and fix bugs; the same way, the maths nerds could come in and fix UI bugs.
In my current job, we'll be a smaller team, so I will have to take care of a lot more code.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
>In general one or more programmers are in charge
From what I understand there are generic type of algorithms, each program is made from several of these generic algorithms. When you’re building something you don’t really start from scratch you build with that typical algorithm in mind. They teach you these algorithms in computer science school hence a graduate/junior has an approximate idea what to expect. I don’t have a CS degree I’m just forever making guesses.
|
|
|
|
|
A software is more than just a collection of generic algorithms.
The big part can be business logic (how things work).
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Calin Negru wrote: They teach you these algorithms in computer science school hence a graduate/junior has an approximate idea what to expect.
Not in my experience. Not for any degree.
I remember being with a group in a electrical science lab in school with two older guys that had been working as engineers for years. They had to get a degree to get paid more at the company they worked at.
One of the components that we were supposed to use for the experiment was bad. They immediately knew what the problem was. While I was frantically looking through the provided lab notes and the book (for the class) trying to figure out how they would even know that. That information was not there.
They were kind enough to explain.
Similar situation an offhand comment by someone later on made it clear that when I graduated I would have no idea how to make an electrical board that would actually work in the real world. None of the classes available taught specific knowledge about the extras that were needed for that.
I am rather certain though that I will never ever need to rely on my knowledge of proving why the speed of light actually is the speed of light though. I did learn that.
Far as I am concerned someone who graduates from university/college who has not worked a real job programming does not know how to write code. That is why internship type positions exist.
|
|
|
|
|
>Not for any degree
You’re getting a crash course into it on your first programmer job then
|
|
|
|
|
The product family on which I worked for much of my career contained over 30M lines of code. Various products were built on a common platform. The language, operating system, code repository, and platform were all proprietary. Products were sometimes combined in "superset" loads for customers (telecom network operators) that operated more than one kind of network.
There's no way anyone can understand 30M lines of code, although some of us could look at reasonable subsets of it and figure out what was going on.
Code ownership was important. Before code could be merged, it had to be reviewed by a senior designer in the user group that owned that code. Proposed code changes were usually discussed and reviewed in advance so that time wouldn't be wasted on changes that would be rejected when submitted.
Besides reviewing merge requests, senior designers provided design consulting for junior designers and were assigned the more difficult features.
|
|
|
|
|
In large companies, especially in medical imaging companies I've worked for, the codebase will be large, especially since they have to adhere to the DICOM standard, and regulatory requirements. At least 15 to 25 million lines of code in various languages, ranging over C#, Java, and even browser based frontend languages/frameworks. Perhaps there will be just a handful of people in the entire company who have the big picture of the codebase. A developer will only know his part of the code, just that "I have to fix this bug in this part of the UI, or, add this small enhancement here". Some of the more experienced developers may opt for the managerial path.
However in a small company, it is unlikely that there'll be such a huge codebase. The individual developer's responsibilities will also be high. A manager here will also wear the developer's hat on occasions.
|
|
|
|
|
Greg, Amarnath S
>about 30 million lines of code
That’s a lot of code you guys, that probably must be old code that keeps piling up although it’s a bit difficult to imagine at first different devices using the same code. On a second thought however it starts to make sense, the devices are probably managed using a PC, if it’s imaging devices they have something in common so a base class could be used for all of them etc. Chances are I have no idea what I’m talking about sorry if I’m saying funny things.
modified 24-Oct-23 10:37am.
|
|
|
|
|
Calin Negru wrote: I’m curios how much can a single person do?
Where I work (and I suspect at most other shops) we follow a crawl-walk-run process.
Regardless of whether you're a new grad or an experienced developer, the first tasks a new dev gets are crawl tasks (e.g. "change a string in the app"). The purpose of this task is not to confirm that the engineer knows how to change a string, but rather to give them enough time to get familiar with the codebase and the engineering process followed at the company. A crawl task is a low risk one that doesn't impact the release.
Walk tasks are usually bugs where the dev needs to do a fair amount of digging around and will likely require them to ask deeper questions.
Run tasks are standard deliverables that assume the developer is able to hit the ground running when they take on these tasks.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: A crawl task is a low risk one that doesn't impact the release.
that shouldn't impact the release 
Wouldn't be the first time someone makes a typo or is just next level incompetent
|
|
|
|
|
No, doesn't impact the release. The decision to assign the crawl task to the dev is made only after the tasks have been evaluated.
/ravi
|
|
|
|
|
Depends on the programmer, company, codebase, etc.
If code is stable and doesn't change very often, you can be responsible for a whole lot of code indeed! 
|
|
|
|
|
And that's a good question.
A programmer can handle a fair amount of decently designed code without so much problem. Documentation helps and the first thing/best way to learn a new code base is to work through it, documenting as you go. I've managed to maintain something like 6 large projects, (2 WAN, 3 Intranet, cloud utility) and it wasn't real hard.
On the other hand and this is where I got tripped up, there was a report that discussed that one of the hardest/most aggravating things for a developer was having to work with technologies that they didn't have the time (resources) to master. Then you are just outside of your comfort zone all the time. The article was in relation to DevOps. While it isn't hard to maintain a number of large code bases because you are comfortable using the same technology in them all, DevOps means that you are switching technologies, some of which may be unfamiliar, hard to master and ever changing.
A heavy load of similar tasks (multiple large code bases, applications) is not so hard to manage. A load of many dissimilar technologies can be crushing. I loved that one CEO didn't want to come out and say that DevOps was hard to maintain. He said there was a bandwidth problem. There are many good developers, but not near as many that can handle the demands of DevOps. I can handle it, a bit uncomfortably if it includes much cloud, but in my long career I have only known a few developers that were comfortable in that storm. What I wonder though is for all his impressive mastery, was Bill (all bow down to Bill) going to be able to keep up with the changing technology.
|
|
|
|
|
Everyone else seems to have gone rather meta in their response, so I'll give you my 2¢ concrete example.
I just passed the ⅓‐century mark at my current employer. Our active code base includes several products and some items that were originally written in 1999-2000. We have in the neighborhood of 40-50 million lines(*) in that code, ¼ of which is my direct responsibility. Most of that I created originally. Some of it I inherited from others when they left the company.
Obviously on any given day I'm not working on all of that, and I certainly don't remember any more than what I'm working on at the moment. Working on code I wrote is more comfortable since I know what to expect. In a lot of cases, working on the code others wrote originally is okay but it's not my favorite thing. There's one product where I've only made a single change in the several years I've had it, because the original author wrote it so that he was the only person who could maintain it [3,000 words of angry, profanity-laden diatribe omitted].
(*) Yes, I know line count isn't a meaningful metric for code size. It's useful for casual conversation.
Software Zen: delete this;
|
|
|
|
|
Back-of-envelope calculations: 33 years, 48 weeks of 5 days, that makes roughly 8000 days.
You are responsible for 10-12 million lines, most of which you created originally, you say. Let's say 8 of those 10 million lines.
So every working day for 33 years, you have produced about a thousand new code lines, going into you employer's repository. Wow!
I know for certain that I have never been even close to that, delivering 5000 lines of new production code to the code repository every single week for 33 years! I could never get close to that. I suspect that few others will.
|
|
|
|
|
There is some duplication in the code base coming from forks for new products or new generations of existing products. Over time there is drift between the forks which means tracking the differences. There have been times when I've applied bug fixes in 6 or more places.
Still, I am pretty productive. Some days I can write 2,000 lines without breaking a sweat. Other days I only get 5 lines, and 2 of them are dodgy  .
Software Zen: delete this;
|
|
|
|
|
For a small business with only a few custom apps, would say 3 to 6 months to become competent with the code. It depends a lot on how the code was written and how well the code matches the skill set of the coder.
|
|
|
|
|
A developer will be responsible for all code he writes.
Add in a ‘helper’ and you’ll get a bungled mess, because the added person will never fully understand the context and code: the primary developer will have to split their time between coding and teaching/fixing.
 Hard truth: the person responsible for breaking it is responsible for fixing it.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
I don't think there is ever too much or too little. Although within reason.
I think we can owe Dave Cutler many thanks for the Windows NT kernel and whatever else goes with connecting that to Foundation Classes. Torvalds for Linux, Stallman for GCC and EMACS (many nameless heroes for creating or porting to GNU). Of note, I think Tim Sweeney loves to reinvent Unreal Engine every 10 years or so.
But I guess if you own it and love the project, Sky's the limit.
Ken Thompson...that guy's a machine (I mean B, UNIX, Plan 9, Inferno, UTF-8, Go) and I think he once reverse engineered (hacked) one of the predecessors of the Inkjet printer.
Yes, they all weren't alone but I'm pretty sure they were compiling most of the source code in their head.
|
|
|
|
|
Unless you're prepared to spend time "reverse engineering" and creating "structure charts", you'll never have the big picture and will create more bugs as you try and fix exisitng ones; or make enhancements.
How big is big? There are departments and enterprises. A few days to a few months to "figure it all out".
As a "project manager / lead" and "single person", you get to do it, and "own" it all.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
