I think it’s OK for a senior developer to suggest what the best place for changes would be, if they know the code well enough to do that, and the more junior developer doesn’t know the code that well.

If it’s a very complex change that needs to be applied in many parts of the system, then trying to micromanage all of it will most likely make everyone miserable. In that case, they should provide more general guidance and let the junior developer learn on their own.

Never be afraid to ask for clarification on something. CYA, always. If it’s a job too big to grasp, chances are you aren’t meant to. Ask the lead developer “I understand what I need to do, but since I haven’t needed to work on the architecture, I don’t know where I need to do it for sure. Can you please help point me to at least the general area?”

When I was a dev lead last time (full of juniors, most of them were last year students on CS MSc), I had a third approach:

1. Give the story to the junior dev
2. Tell him to come back with a plan how it would be solved
3. After reviewing the plan, but only after, start editing files.

I don’t say it worked quite well.

For simple tasks, like, add a new column to a report table, they did a huge mess, editing all the files, then they said “it’s already done”, then we reviewed it, turned out it’s not the way it should’ve been done, they had to revert nearly everything (1) and then start again.

On big tasks (5+ classes involved), it was on the other side: they were simply silent for a day or two, then we had to go through it together, and basically I drew up a design which they had to implement.

Although I was there and for every single decision I explained it to them fully, and they had the required readings before, and it was more like a demonstration (2), at the end of the day, they still had to implement my design mostly, and they weren’t that happy about it as when they’re let free.

I know it’s hard to differentiate planning from doing, but I guess it’s called software engineering because there are still a few individuals left who know what they do, as opposed to craftsmen. My duty as their trainer was not to create another average coder, but someone who excels in his profession. Luckily, today, all of these are teamleaders (or were, but joined a different, more “agile” company with no leadership)

So, all in all, I don’t know what’s best, I only know that code quality is more important than junior’s convenience – they’re there to learn, not to let any kind of code to be commited to prod…

(1) (“Why? It works, doesn’t it?” “Yes, but you’re querying database from the view layer or such”)

(2) (“you see? we need this, and we usually use this pattern for this as you seen in this other similar module; here, our coding guideline (which was 2 pages long) says, do this, so, let’s do this, and then ,let’s draw a sequence diagram on how it would work… ok, now let’s draw a class diagram about it”)

I think it depends on the devs skill level. Trust me, it’s usually not easy for the senior dev either. I would take it as compliment that they trust you to determine how things are done. Just make sure you run your design passed someone else before doing the work.

As a note, you shouldn’t blindly trust what the senior guy is telling you. Do your own analysis and if what he tells you doesn’t make sense, push back and ask questions.

It depends on the core architecture of the system. Some of them (including some really big that I have seen from inside) have NO internal structure, to me they merely are collections of parallel solutions to a bunch of tasks, eventually forming a system or framework. In these cases, it can be an open question if the senior should or should not tell such things – and the answer likely depends on taste and habits. I prefer another way (which is a subjective judgement, it took me several years to create this architecture).

I was a lead programmer in a country-wide data management system. This means a rather “horizontal” application structure: lots of guided data management on hierarchical data structures (like personal data, property information, …) and higher level actions: tender application and progress workflow, filing, notification letters, etc. I am sure that without a clear internal structure such systems just collapse in time because of their own weight (keep all old stuff but constantly change all existing tenders, letters, while adding new ones; most of the time working under irrational deadline pressure).

So we have created support components (“toolkit”) for database access, direct data manipulation screens, forms, letters, workflows, …; and high level services, like a filing system capable of collecting, displaying any document of any type for a case of a client, or the form manager that was responsible for let the client fill a specific type of form, it (and not the form business logic) managed the filing, storing, etc.

Behind this structure we had configuration tables where the individual gui declaration, the associated business logic, etc. had to be registered, and if it was there, the feature was integrated to the system. Of course all components had clever abstract base classes, so most of them were ready to use (like managing the new hierarchical data type in sometimes multiple data tables) by configuration, without any coding.

Consequentially, the mentioned question NEVER even appeared.

• NO, I have never told anyone the name of the classes (I would have done it in case of name collision among the multiple modules – this never happened).
• NO, never told where to put it (it was the responsibility of the team working on that specific area, designing their own package and protection scheme).
• YES there were exact configuration settings that they had to make to have their components and codes work in the system.
• YES, there were several base classes to derive from, with exact locations where they should add their specific code, and API to access other system components. All created based on experience of developers working on that field for say 5-10 years (not on my personal ideas), and eventually had tens or maybe hundred working examples to similar tasks in the same system.
• NO, there were absolutely no “shortcuts” allowed. If they were really important (without an acceptable workaround), they were also integrated to the toolkit layer. In some cases, months or years ago 🙂
• and sorry, YES, the wiki documentation was always behind the features, because most of the stuff was designed and implemented “backwards”, by grabbing the initial features from actual tasks and constantly adding new services, instead of planning forwards.

The system lives today, many years after I have left the company (therefore this is only my subjective opinion, they may think differently), and as far as I know, reused in new systems. The only problem is that working in this environment is boring. (Or they are too polite to tell the truth… 🙂 )

None of them

Ideally, there should be a design meeting of technical details that you are planned to implement in a team environment. That is the right place and time to identify most of the questions.

Another point is – Communicating clearly what developer does not know is very important. Never be afraid to ask questions on domain specific details and requirements. This will assure that you are on a right path 🙂

In important thing that newbies forget to do is, to Google for technical problems first before asking to the Team lead or Senior developer for help.

The team (or lead if your team is less democratic) should generally come to some sort of agreement on design. There’s other ways of getting stuff done though, so I imagine it will vary depending on where you’re coding.

If you’re having trouble grasping the structure of the codebase or don’t know how best to design the new feature, ask your lead or peers. Part of making good process is collaboration with your team.

I like this question. As a software architect, my manager pulled me into his office for a 1.5 hour “chat” about how it IS MY RESPONSIBILITY to ensure that every line of code that any other developer on the team commits conforms 100% to the coding standards and architecture of the application, and basically that logic is in the right place (i.e. if a dev commits code that contains business logic coded into a button click handler instead of a business layer, then its my fault). However I was also told that we a) can’t do peer programming, because it is inefficient, and b) I don’t have time to do code reviews. (yes, I’m looking for a new job now).

Anyway, what I told him is that no, it is NOT my job to tell developers where to put their code exactly, but rather it is the architect’s job to make the application framework and layout as intuitive as possible for the devs to determine where code should go, and to make it as easy as possible for them to put that code there.

Some software architectures can do a good job of guiding this too, for example in an “onion architecture”, the UI would not have a reference (at a project level) to the DB, so you couldn’t possibly put DB code in the UI button click handler (unless the developer adds the missing reference of course, which you usually also can’t really prevent).

What I do consider a good technique:

Peer programming. Especially when senior level people are paired with junior level people. If one person doesn’t know where code goes, the other might. Or a peer might notice someone slipping code into a place that doesn’t conform to good software craftsmanship principals or patterns.

If you can’t peer up to code an entire feature, then one good way to go is to get the requirements (or acceptance criteria for a story / feature), and have the architect and the feature programmer peer up for a couple hours and write all the unit tests to cover the spec. Yep, I’m talking test-driven development here. Those unit tests are usually set up to indicate the design and where code would have to be to make the tests pass. Then the (broken) tests can be handed off to the feature programmer to code alone, but his design will be largely guided by the tests, which the architect helped arrange. It really does work out well when you can’t to full-time peer programming, and have programmers familiar enough with or willing to learn unit testing and TDD!

The latter job is hard, if the software I am working on is too big to grasp the structure. Should senior guys tell the place to add the code before coding?

Part of the job a lead to help grow the skills of those around him. Growth is not possible if you are never given a chance to solve the hard problems. The lead should be there to help, answer questions, and put you back on track if you need it. In general they should not give you the solutions. You should come up with the solutions, possibly with their help, and certainly with their guidance.