|
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
|
|
|
|
|
|
How much code can a coder be assigned to be in charge with
As much as they can handle and then some.
The only real answer is "it depends", but I don't think you can ever say a developer can only be in charge of X amount of code. The dev should be in charge of all the code that their job requires them to be, which is based on business case / security / level of responsibility. If there's simply too much then the load needs to be shared based on who else the business can afford to hire. And in some cases devs are simply in charge of everything, and in charge of too much. That's just life.
cheers
Chris Maunder
|
|
|
|
|
I think I may have found a use for it I can get behind.
code generation synthesis
Code synthesis is similar to traditional code generation in that it creates code given some input.
The dramatic difference is the output. Code synthesis looks like the code was written by hand. Typically code generation looks very regular, and you can tell it was done by a machine (or a very methodical and painfully boring person maybe)
This is maybe most evident in parsing code. Generated recursive descent parsers use FOLLOWS sets whereas hand written parsers are typically and for lack of a better term more "passive" in that they don't care what symbol follows the symbol they are currently parsing. They don't rely on lookahead as much. It's hard to explain this but easy to see it if you compare say a hand rolled JSON parser with a machine generated LL(1) based JSON parser.
The trouble is, I have no way to do code synthesis outside maybe some very narrow cases, but I'd like a more general approach - something I can train to produce code to solve any number of different problems.
I'm thinking AI might be the ticket. I know nothing about it though, as AI is big tech and I'm all about small tech.
If anyone reads the above, can understand what I mean, and has even some sort of baseline experience with this "AI" stuff, please tell me what you know. I don't even know if it's realistic or where to start looking. Anything at this point, penny for your thoughts!
Thanks folks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
You need to start somewhere: i.e. "primitives". AI won't create primitives (chicken and egg). Once you have the primitives, then you (or "AI") can start thinking about assembling them in different ways.
"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
|
|
|
|
|
I need to determine what a model would look like for some kind of code synthesis and then grow it from there, even if it was one for a particular type of code generation, but I don't where to start.
When you say primitives, do you mean like programming primitives, like intrinsic types and such? Or do you mean some sort of "AI" concept I'm not familiar with yet?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Primitives are what "comes before". And it depends on your model. If you want to "generate constellations", then you need stars. "Generative AI" is where you tell it to write stuff; or draw stuff. You need to find your stuff.
"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
|
|
|
|
|
My code works in my initial tests, but as soon as I try to run it in the real world, boom. Nothing happens. Not even any errors, just ... nothing.
I spent a week and a half building it and getting it to run through my initial tests successfully.
For me that's a long time to spend on code. I spent a week on Winduino, which is fairly substantial.
I can't figure out why it's not working, and yet outside my offending code there's a lot going on in the real world case so it's hard to narrow down where the problem might be coming from.
Also debugging is only helpful to a point because of the way of the my rasterization works - you get lost even following routine by routine. There are qsorts, edge detection, poly fills, allocations, deallocations, etc so it's hard to know what it's doing with the data I'm passing it. Unfortunately it can only be so factored and still be performant.
I'm frustrated with it, and done for now, but I wish I wasn't because it's 3am and I'm wide awake.
I may have to start over.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
hmmm nothing.
Is is spinning with high CPU usage (or high memory usage), or caught in a deadlock wait?
|
|
|
|
|
Nope. No threading, and the thing runs, even after the fact. Everything goes except my SVGs which is what this code is about. It can still parse SVGs from a file, but if built manually the above happens. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
interesting. (frustrating but interesting).
I must confess to being an old, crusty, developer. So here goes.
Add conditional code (via macros or assembly directives that are dependent on a keyword) to define a log file.
Pick spots in you code that you absolutely know have to be executed (start with file SVGs first)
Only use a few prints to the log, you only need to prove that the code is executing the way your brain is telling you it is executing. Then switch to manual SVG test. The log file should be the same. If it is not, then this is the paradox you are looking for. You are absolutely certain that the code must be executing but it is not. You can then concentrate on figuring out why it is not. If the log is identical but the manual SVG is still misbehaving, then you must refine the granularity of the prints by inserting more until you can prove all of the code is executing and still not producing output. (obviously this is not possible, but we are looking for a paradox. A point in the code that is deviating from the norm.)
I know this is not the sexy way of using real time debuggers, but I can not tell you the number of times that I was absolutely certain a piece of code was being executed, only to find it exiting out of a loop early for a reason I forgot about.
Hope this helps a tiny bit.
Good luck.
|
|
|
|
|
I haven't been using a debugger. At this point I'm so used to coding embedded that I've found it's almost quicker not to use one. So what you're suggesting is kind of what I've been doing except more.
It's a console app - see my 2ascii project I recently updated here - but I've hijacked it to test my SVG builder code.
Since it's just console I use fprintf(stderr, "foo"); to "log" 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
