It's hard to judge this objectively, since you seem to be painting your differences from Mr. X in a particularly "new v. old" light.
A few examples:
X says that we should be using "special character" separated strings - without using a lib/wrapper that hides the underlying implementation.
Why does he think that way? Has he tried going down a JSON route before, only to be confronted with an edge case or peculiarity that makes his method simpler?
And this part jumped out to me:
For example, I say - Let's put in 10 more days and make a generic solution to create similar forms for 30 db-tables ... (time is not a problem)
Ten days is a lot of time. Can you put together an argument that the generic solution is worth that time even in the very long run? You say time is not a problem, but how is that possibly the case?
>"Why does he think that way? Has he tried going down a JSON route before, only to be confronted with an edge case or peculiarity that makes his method simpler?"
I was actually about to comment on the same thing. Depending on the case a simple solution would be faster to implement and potentially easier to maintain, but as always it will depend on the requirements
Here's my breakdown (disclosure: I'm an old fart but used be a young gun)
JSON: go with the more standard JSON, "special delimiters" sounds brittle --> old fart loses
customers: don't solve their problem unless they paid for it or it's very small (<1hr). If it's a good customer they'll understand, bad customer will ask for more and more --> old fart wins
functionality: restrict if it's a headache to support unless it's something everyone else has already has --> tie, old fart and young gun should discuss it
genericness: big warning sign! In my first few years I was always building frameworks, now I solve problems. When the time comes to build a framework you'll know it but it takes many years to develop that wisdom --> old fart wins
To make matters a little harder the old fart seems to naturally have encyclopedic knowledge or was forced to develop it in a day and age of printed manuals (I remember those days and am glad they are gone!) The current generation of programmers has less need for rote memorization but keep in mind that there's some value in encyclopedic knowledge beyond the pure facts. If you know a lot of stuff without having to look it up your brain also becomes better at algorithmic thinking because you have more data to practice on. Sadly, my own memory has never been so great.
As far as JSON, this is the part that's telling to me: "without using a lib/wrapper that hides the underlying implementation." It sounds like he's arguing about generating it directly and parsing it by hand, although without context, I can't say for sure. If that's the case, I'd say the old fart is right on this one.
As far as facts, if you know a lot of facts, you can reason about how changing one fact (eg, "we write this value to this SQL table here, and we are going to stop doing it") allows you to reason about how other facts are affected ("Modules X and Y expect that data to be there").
I wasn't clear on that example. If he's talking about CSV, there's nothing wrong with that (though I wouldn't call JSON "bad"). If he's talking about delimiting text with the bell character, yeah, that's ghastly.
> without context
I feel like most of the examples don't have enough context to make a fair judgement.
If it's just a small amount in one place, simple formats like CSV and JSON can easily be parsed, and especially generated, manually. If they're used all over the codebase, manual parsing would create a huge amount of duplicated code. There just isn't enough context.
I disagree with him on the first; character-delimited strings are a pain. If you're going to hand parse, you're better off with a <length>:<bytes> encoding like Bencode uses. You don't have to escape the string, you can copy a whole block instead of scanning character by character and it plays well with UTF-8.
Thanks for pointing that out. I started coding for profit in about 1990 so I was thinking more along the lines of 15+ years of experience as the old-fart cutoff.
JSON: go with the standard "special delimiters" sounds brittle --> old fart loses
nah. depends on context. given a large existing codebase that already has effective communication implemented via special delimiters, recreating that same functionality in JSON really does not make much sense.
These are interesting scenarios. Each of them could probably use some additional context but overall I think the problem is one of practicality vs idealism. I have been in both parties over the years and have more often than not been in the camp of over-architecting a solution. I think that on the surface, he does sound like a very practical programmer who is cognizant of the bottom line. If you are not going to be paid extra to implement something, then sometimes it doesn't make business sense to implement it. It is sad but true and you will sometimes feel the same if freelancing. To me, I would not turn my back on this guy - it does seem like there is stuff to be learnt from him. Nobody has all the answers though, so it is good for you to question him. If it is possible, maybe open dialogue with him about these would be beneficial to you both.
I agree with this response. Specifically highlighting the problem being a matter of practicality vs idealism. One of the things you learn as a young programmer is that bad code is inevitable when your resources are limited.
A practical generic solution, for example, that takes an extra 10 days to do, sounds fantastic from an engineering perspective-- we're trained to think this way. But on the business side of things, you may have a timeline for a feature to nab a client, or not enough budget for those extra 10 days, etc.
My opinion on these matters now generally falls into the it depends camp. Take his mentorship, because it sounds like he understands that every engineering solution is accompanied by a business solution and they must be agreeable for both parties (that said, he does seem a little jaded, so you don't have to take absolutely everything he says to heart-- there are companies who will give less weight to the business side of things, but the reality is that the consideration will always exist).
> every engineering solution is accompanied by a business solution
This cannot be stressed enough. Replace "business" with X. Engineering is rarely isolated. More often than not, constraints on time, budget, usability, customer relations, etc... are just as important as the down-and-dirty engineering constraints themselves.
This applies to all engineering. It is much more obvious, in some fields than others, though. E.g. material costs are easy to perform a cost/benefit analysis on, whereas software is generally more abstract.
One of the big things that made me think about it like that was his stance on generic code. As in my experience it tends to lead to over-engineering, and less efficient code (as you need to account for more things).
It's takes some experience to know when the extra effort is worth the time; and it sounds like Mr. X very well slanted towards practicality ... throwing a little idealism at him where you think it's needed... AFTER you understand his reasoning... will make both him, and you better at the end of the day.
If you replace "because" with "bcoz", my assumption would be that you're wrong or sloppy about other things. There was a popular book titled "Dress for Success" that was all about appearances ... Appearances aren't just looks anymore and you should be careful how you represent yourself digitally if you want to advance.
EDIT: Rereading that it sounds a bit harsh ... it's perfectly fine to abuse a language when you're communicating with your friends (some friends anyway). As an architect, you've also got to communicate with management. Practice by playing some buzzword bingo, then write coherent and grammatically correct sentences using those words. You may in fact be smarter than this architect, but you have to convince everyone else too. (Actions speak louder than words, but also choose your words carefully).
Since that is the only example of such language in the post, while there are many more opportunities for sloppy language, I think he originally wrote it fast, with more of such abbreviations, and then filled it out. So I think he just missed one and does care about appearances.
Perhaps ... and he/she may not even be a native English speaker. I don't generally categorize people by how they talk or write, but upper management probably will.
You don't get to pick your mentors. They just happen. I have a lot of people I consider mentors, and none were "assigned" to me. And the ones that were assigned? They tended to be the absolute worst people to learn from, if for no other reason than they felt they had to impart wisdom and be smarter and justify being a "mentor".
Learn from him, sure. Maybe that means learning what not to do. But "mentor" isn't the word you're looking for here, I don't think.
That is the answer! I already had this problem too. You can learn a lot, even if the mentor is awful. You will be challenged a lot to put your point of view in the code, maybe you even discover you are wrong about your arguments.
If you really think you can't learn anything from him, probably he is the right person, you have a lot to learn.
He sounds battle hardened (and like he has a mortgage, which enforces a certain lucidity.) You should definitely listen to him and take him seriously, if you want to assign him the symbol of "mentor" in your head, that's up to you.
Yes, this exactly. This is partly why engineers have trouble learning the art of management because in management you have to sometimes put on the business hat that says do the most expedient thing rather then the craftsmanship hat that says every project and feature should be treated as an enduring testament to engineering perfection.
You need to understand more than just the art of software engineering, you also need to understand the business, the customers, the stakeholders, the roadmaps, and generally the reason why things are moving in particular direction. Your mentor should be sharing as much as they know on these topics instead of just mandating implementation details without describing why.
He probably has a very good understanding of the company's priorities and politics. Pay more attention to that. Politely disagree on the tech side when you think it's appropriate, make your arguments, and then implement based on what comes out of that.
On stuff like JSON vs. custom delimiters, that's old thinking - you can probably win that argument by finding out exactly why he thinks that way. Chances are that he's concerned about bandwidth overhead or something similar, or he's thinking about the effort of implementing it from scratch. You can argue against the former by doing some tests with your webserver's mod_gzip, and the latter by coding up a POC with a JSON library and showing him how easy it was.
Being mentored doesn't imply that you have to take everything they say as gold. Approaching their advice with a critical but respectful attitude is probably best.
I'm skeptical about a developer who doesn't like JSON, however it's not clear what his reasoning is from this little anecdote. Maybe there's already a large amount of code using the custom method, maybe the data is not that complex and there are layers that don't have ready access to a JSON parser.
A lot of the rest of it sounds like simple pragmatism and YAGNI which is something many young and brilliant developers need to learn. That said, if he lets copy and paste code multiply and not be refactored and relies on his perfect memory of the codebase to update multiple places then that could be a red flag.
Anyway, if he has the patience so explain the reasoning to you and gives you some war stories I think you'll come out better for having listened.
It's very hard to impossible to really judge based on these short examples but I can totally relate to both of you. E.g. if you see a feature that seems to be free in terms of coding it is very hard to resist offering it. If you do that over and over you realize there are at least two problems with this:
* It's never free. Do you have tests for this? + it will restrict your way you can refactor the code.
* Product features are not always good, product complexity is actually a bad thing and it is unlikely that you don't increase it.
That said, it will make some users happy, so it may be worth it - all I'm saying is that this should be a conscious decision, it isn't a no-brainer.
Mentorship does not mean being reshaped in the form of your mentor, as if you are supposed to become a carbon copy of them. It means learning from someone more experienced than you in a more controlled environment. And not just learning from situations you wouldn't normally find yourself in and thus benefitting greatly from specific context, but learning from a different perspective that you can incorporate into your own. You are being given an opportunity to grow and diversify your way of thinking and executing. Embrace it.
It maybe a good idea to get a Mentor for different aspects of your life. Pick and choose the talents/qualities you want to emulate, don't just copy and paste their actions and beliefs.
The tech lead sounds like a very pragmatic developer who just wants to get work done quickly without hassle. This is not necessarily a bad thing but it does not mean he is always right either. He probably has most likely opened up a few cans of worms and as a result is very conservative in his approach. Younger people tend to bring a lot of energy, but sometimes come into a company and want to shake things up - then they get bored and leave a bunch of fad-oriented programming code for the remaining team to maintain for 5 years.
The copy/paste would be a warning sign to me, but it could also be that he knows a generic solution would become extremely complex with problems that you do not yet have the experience to forsee. It's not really possible to understand which is true based on your email.
Anyway, I would try to get more information from him to see if he is being lazy or pragmatic. When he says thing that you disagree with - have him explain it to you. It might be that he has very good reasons - or that he is just resisting new technology that he doesn't understand. I would try to find that out first.
All that being said - you can learn a lot from a bad situation as well as a good one. You can learn what not to do!
It's hard to characterize someone based solely on a series of vignettes but they do seem a bit familiar. I've worked with people that seem similar to Mr. X and, at least a couple times, have had to report to someone like him.
In my opinion it's important to keep one's idealism and practicality balanced. For instance: solving the company's problems first and letting the customer solves their own strikes me as both practical and reasonable. Opening one's mouth and recommending that code be literally cut-and-pasted repeatedly may sound practical, but in practice I've learned that's rarely the case.
I think the perfect mentor is nearly impossible to find. I believe that I've been well served by reporting to a variety of different personalities and striving to emulate those things that, as far as I could tell, where helping them succeed. That's a bit of a punt, but I don't think there's an easy answer here.
I think the answers is Yes, absolutely. But I think I have a different idea about what the mentorship should involve then you do. I think you can learn more from studying his thought process and his experiences with sr. management, customers and partners then you will from simply following his technical suggestions.
I also think you should bring a couple things to the table that you want to teach him. It could be some new fancy tech, or some online community or something that will help expand his perspective and better understand where you are coming from.
At the end of the day, it is really relationship problems that hold us back - not technology problems. And your ability to form successful mentor/mentee relationships will help you much more in the future than learning new tech of the week. (It will also give you perspective when your future mentee posts to hacker news v.next about her stodgy old mentor that doesn't know anything ;)
Like others have mentioned, it's hard to know which approach in each of your examples is best without digging in more.
Assuming his approach is indeed better than yours, what I'd be worried about is that he hasn't explained to you why his approach is better (or you weren't listening). A good mentor needs to not only be able to do things the "right way" but also articulate in an easy to digest manner what makes it the right way.
You need to express your desire to learn from him and ask him to explain why his approach is better. If he can do that well, then he'll be a good mentor for you. If not, then not.
This guy is crazy... seems like he's trying to get stuff done in favor of engineering new problems that require more technology and longer development time...
Kidding aside... I think by posting this you already had your answer.
1. Respect and learn from everything mentor says.
2. Try out all the things mentor suggests that you have time to try out.
3. Throw out everything and do what you think is best.
Sometimes you'll be right, the clouds will part and you will feel the warmth of the sun on your face. Other times you'll be wrong and will humbly think "mentor was right that time".
But, at the end of the day its your name attached to those lines of code, its your career, and your life. Survive by your own cunning.
And, while we're doling out life advice- I strongly suggest standing up often.
I'm not the most agreeable person in the world. I don't really like being disagreed with and I like to do things my way.
I've learnt 2 lessons: I'm not always right and you can agree to disagree. Ask questions such as "How did you reach that decision?". If they can't convince you, calmly give your reasoning behind your decision. Worst comes to worst, agree to disagree and let your line manager make a call. Go with it and learn.
There's something to learn from everyone. I suggest if you find yourself not agreeing to his advice, keep it in your head anyway. When you find yourself facing a problem his advice described (and you aren't working with him for that problem), think about ways his advice would apply, and ways his advice is not relevant, and make your own decision.
I'm not a developer, but I've had a very similar experience. It sounds like Mr. X is just trying to minimize the amount of work he has to do. Usually in these circumstances experience wins, especially if you want to have a personal life. Don't stop suggesting change though, just get used to the idea that only your best ideas will make it through.
The truth is all the good stuff you mentioned / believed in is not important or even irrelevant in a lot of contexts. Try to learn from him on judgement within a context, instead of sticking to whatever fancy things/rules you learn from a textbook or the internet.
3-4 releases a year sounds like there might be a solid QA cycle involved. e.g. I used to work on a webapp for flight planning: how much fuel should go in the plane's tanks, etc. It's not the sort of application that should be live-updated by the developers every 2 weeks. Maybe the mentor here has a clear view of the product lifecycles appropriate for this organization.
I don't think we have enough information to decide who's right in any of the OP's situations.
3-4 releases per year should be a red flag, but unfortunately it's atually pretty common in enterprise environments. Hopefully they are shipping code much more frequently, and packaging it up and calling it a "release" every 3-4 months.
Odd, I've been making releases of my product at least twice a month for the last year, and it's been increasing steadily lately too. I always thought it was a good thing?
I think you should listen to this guy, because while you're busy making something generic, he's changed it ten times and cut and paste it after each change.
You need to be a lot leaner and then make things more ideal when the code-base freezes: which is never.
For example, with JSON is nice if you're sharing data with others. But parsing anything can be done in half a minute by hand.
Likewise, if you start making changes that should be on the buyer's end, you're now consulting for free instead of working on your product.
etc etc etc. I say go with him.
After learning everything he has to teach you, you will find that some things are still easy to do your way.
The reason he REMEMBERS where you don't is because he's thinking leanly about the actual feautre; he doesn't care what the code looks like (within reason) to support it.
There are arguable shades of gray in those examples but the JSON one and this one:
> X says - Lets make those by copy-pasting - and later we will think about making it generic
... are pretty ill-informed. That just reeks of sloppy and lazy and not particularly concerned about his craft. If you're looking for a mentor I would think you'd want to align yourself with someone who is mindful of their craft, no?
I hate this knee-jerk response so many have that copy/paste == bad. You aren't in any position to create a generic API until you have at least 3 implementations, so unless it's a very obvious solution service, or you are practising some kind of extreme waterfall, copy/paste could be the best way to go. I'll hypothesise that most of the architectural problems we have are down to the cult of prefactoring.
A few examples:
X says that we should be using "special character" separated strings - without using a lib/wrapper that hides the underlying implementation.
Why does he think that way? Has he tried going down a JSON route before, only to be confronted with an edge case or peculiarity that makes his method simpler?
And this part jumped out to me:
For example, I say - Let's put in 10 more days and make a generic solution to create similar forms for 30 db-tables ... (time is not a problem)
Ten days is a lot of time. Can you put together an argument that the generic solution is worth that time even in the very long run? You say time is not a problem, but how is that possibly the case?