|
>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
|
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
