|
Wordle 857 3/6*
π¨β¬β¬π©π©
π©β¬π¨π©π©
π©π©π©π©π©
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 857 2/6
π©β¬π¨β¬π©
π©π©π©π©π©
|
|
|
|
|
Wordle 857 6/6
π¨β¬β¬β¬π©
π¨β¬π¨β¬π©
β¬π©π¨β¬π©
β¬π©β¬π©π©
β¬π©β¬π©π©
π©π©π©π©π©
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 857 3/6
π¨π¨β¬β¬β¬
β¬π©π©β¬β¬
π©π©π©π©π©
βThat which can be asserted without evidence, can be dismissed without evidence.β
β Christopher Hitchens
|
|
|
|
|
Iβm curios how much can a single person do?
How much time does it take to become accustomed to the codebase youβre employer?
If youβre willing to talk about this, Iβm curious about this too, how does the division of work take place in the software engineering field, what does a senior do and what would a junior do.
modified 23-Oct-23 16:23pm.
|
|
|
|
|
Since there is no context, many projects here are done by a single person, so all of the code would be an answer, for here.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
βallβ is too broad, lines of code or pages is what I had in mind
modified 24-Oct-23 14:38pm.
|
|
|
|
|
All of it. No design by committee, no politics, no "he's not doing his share".
modified 23-Oct-23 16:50pm.
|
|
|
|
|
Exactly.
The codebase could be huge. Being "in charge of it" doesn't infer someone needs to understand every nook and cranny.
If very little of a large codebase ever needs to change, a good developer - even if completely unfamiliar with it - should be able to isolate which parts he needs to understand, and focus on that.
|
|
|
|
|
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!
|
|
|
|