12 ms·

I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations". Software en

I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations". Software engineering has more to do with people than with software. Have you checked Peopleware? Also, perhaps The Phoenix Project could help as well.

markus_zhang 6y ago
One thing that I really think a lot of SE teams should do is to include a full time BA with them, to fend off irrelevant requirements, mine real requirements and write requirement docs on Confluence. I'm currently in that position, but sadly I'm in a business team, not in SE team, which makes my work only half relevant. The perfect BA should be someone directly from a SE team but with more people skills and are willing to take the burden of that position. He should be expected to increase the efficiency of the WHOLE team by say 20%.
- dopidop 6y ago
  My two last position were in team where all members have a technical background. Like, we just assume you can code or query whatever. Devs are not magical creature. Coding happen to be their main focus. - A bunch of devs. - A BA exactly like you described. Usually 50% on one team. - QA lead, able to pull from the set of devs at will. Must have deep automation and QA skills. - A scrum person ( 20% on the team ) - a tech lead.
yura 6y ago
>I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations". I agree, that's why I'm asking this question. I think these particular books are mostly helpful to the junior engineer. But it's hard to believe that from here on out the only thing that's left is to learn how to deal with people. Surely there's more to the software side of software engineering than what TPP and Code Complete have covered. Surely very experienced engineers have written books on software engineering that cover something more than entry-level knowledge. (Clearly, since I haven't found such books yet, there's a chance they haven't been written. But I find that hard to believe, considering the broad audience of software engineers that are interested in that knowledge.)

markus_zhang 6y ago

One thing that I really think a lot of SE teams should do is to include a full time BA with them, to fend off irrelevant requirements, mine real requirements and write requirement docs on Confluence. I'm currently in that position, but sadly I'm in a business team, not in SE team, which makes my work only half relevant. The perfect BA should be someone directly from a SE team but with more people skills and are willing to take the burden of that position. He should be expected to increase the efficiency of the WHOLE team by say 20%.

dopidop 6y ago
My two last position were in team where all members have a technical background. Like, we just assume you can code or query whatever. Devs are not magical creature. Coding happen to be their main focus. - A bunch of devs. - A BA exactly like you described. Usually 50% on one team. - QA lead, able to pull from the set of devs at will. Must have deep automation and QA skills. - A scrum person ( 20% on the team ) - a tech lead.

yura 6y ago

>I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations". I agree, that's why I'm asking this question. I think these particular books are mostly helpful to the junior engineer. But it's hard to believe that from here on out the only thing that's left is to learn how to deal with people. Surely there's more to the software side of software engineering than what TPP and Code Complete have covered. Surely very experienced engineers have written books on software engineering that cover something more than entry-level knowledge. (Clearly, since I haven't found such books yet, there's a chance they haven't been written. But I find that hard to believe, considering the broad audience of software engineers that are interested in that knowledge.)